A recurrent question (well, one of the many) is about STL containers and whether they are thread safe.
Taking Stephan’s words here, the reality is that they aren’t, not as a bug but as a feature: having every member function of every STL container acquiring an internal lock would annihilate performance. As a general purpose, highly reusable library, it wouldn’t actually provide correctness either: the correct level to place locks is determined by what the program is doing. In that sense, individual member functions don’t tend to be such correct level.
// This article tells more about Thread Safety in the // Standard C++ Library: http://msdn.microsoft.com/en-us/library/c9ceah3b.aspx
Yet if performance were not an issue, for instance because it’s not expected a high volume of write accesses to a container instance, but you just want to just make sure that simultaneous writes won’t leave the container in an undetermined state, you may get among other alternatives the parallel containers that come with the Parallel Patterns Library (PPL).
They are basically concurrent_vector and concurrent_queue, so in case you missed concurrent versions of associative containers like map, multimap or hashmap, you may find sample implementations in http://code.msdn.microsoft.com/concrtextras.
Semantic error - change ".... won't live ... " to "... won't leave ... ".
Fixed, @Spell!! thanks!!
Are their allocators thread-safe, e.g. can you create two vectors simultaneously in two different threads?
Sorry, I should have looked at the linked article before asking.
the STL does require some thread guarantees from any implementation. Any number of threads can create an manipulate their own stl containers with no effect to any other threads. This basically implies that the STL containers do not introduce global variables or any kind of non-local effect.
So Yevgen STL containers *are* thread safe, but not concurrent; i.e. don't access a given container from multiple threads.