Thread Safe, Standard Template Library, and C++

[Steven Woody]

hi,

are those containers provided in std thread safe? if not, does the std
( or the language itself ) provide any method to protect critical
section in a thread unsafe operation?

thanks.

-
woody

 

[Barry]

hi,

are those containers provided in std thread safe? if not, does the std
( or the language itself ) provide any method to protect critical
section in a thread unsafe operation?

C++ has no thread language support,
<url http://www.sgi.com/tech/stl/thread_safety.html/>

 

[Steven Woody]

C++ has no thread language support,
<urlhttp://www.sgi.com/tech/stl/thread_safety.html/>

the link you given could not be found.

 

[Guest]

hi,

are those containers provided in std thread safe? if not, does the std
( or the language itself ) provide any method to protect critical
section in a thread unsafe operation?

They are (probably) thread safe as long as no two threads try to access
them at the same time. I say probably because 1) I have not studied all
the requirements of the containers in detail, but 2) while I cannot see
any reason why any of the would use static or global data I do not think
that the standard explicitly forbids it either.

 

[Guest]

the link you given could not be found.

www.sgi.com/tech/stl/thread_safety.html

 

[Stefan Naewe]

the link you given could not be found.

Drop the trailing '/' and it works.

S.

 

[James Kanze]

are those containers provided in std thread safe? if not, does
the std ( or the language itself ) provide any method to
protect critical section in a thread unsafe operation?

The current version of the standard doesn't consider threads.
The next version will.

All of the implementations of the STL that I know of for the
"usual" machines (PC's under Windows or Linux, Sparc's under
Solaris, etc.) are thread safe, but do read the exact contract
each implements. (Modulo errors, of course. There is an error
in the g++ implementation of std::string, for example, although
it's really a very rare program which will encounter it. And
arguably, it's not an error because g++ doesn't claim to respect
the Posix guarantees, but only a much weaker set.)

 

[James Kanze]

They are (probably) thread safe as long as no two threads try
to access them at the same time. I say probably because 1) I
have not studied all the requirements of the containers in
detail, but 2) while I cannot see any reason why any of the
would use static or global data I do not think that the
standard explicitly forbids it either.

The allocators probably do access shared data. The g++
implementation of std::string also shares data between instances
in certain cases. Unless you have a guarantee, it's probably
best to assume that the objects aren't thread safe. (In fact,
unless you have a guarantee, you have to assume that they
aren't, because you don't know what "thread safe" means for
them.)

As far as I know, the standard containers (with the exception of
string) and algorithms in all of the libraries derive ultimately
from the implementation which is now at SGI, and provide the SGI
guarantee, at least when instantiated over the standard
allocator. (Obviously, if you provide the allocator, you have
to ensure its thread safety.) I think that all except g++
provide the SGI guarantee for all other elements of the standard
as well; some (e.g. Rogue Wave) provide considerably more, but
in practice, doing so slows up the components significantly,
while offering little or no advantage to the user. G++ formally
offers a much weaker guarantee, but in practice, the only
exception is in std::basic_string, and that only causes problems
in one very special case, which isn't very likely to occur in
practice.