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.