On Sep 26, 4:39 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2007-09-26 14:54, Steven Woody wrote:
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.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
