is GCC STL thread-safe?

Question

I found contradictory information on the web: http://www.sgi.com/tech/stl/thread_safety.html

The SGI implementation of STL is thread-safe only in the sense that simultaneous accesses to distinct containers are safe, and simultaneous read accesses to to shared containers are safe. If multiple threads access a single container, and at least one thread may potentially write, then the user is responsible for ensuring mutual exclusion between the threads during the container accesses.

http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html

The user-code must guard against concurrent method calls which may access any particular library object's state. Typically, the application programmer may infer what object locks must be held based on the objects referenced in a method call. Without getting into great detail, here is an example which requires user-level locks:

All library objects are safe to use in a multithreaded program as long as each thread carefully locks out access by any other thread while it uses any object visible to another thread, i.e., treat library objects like any other shared resource. In general, this requirement includes both read and write access to objects; unless otherwise documented as safe, do not assume that two threads may access a shared standard library object at the same time.

I bolded the imporant part - maybe I dont understand what they mean by that,when I read object state I think of STL containers

Answer 1

How I understand this:

both documents say the same in different manner. MS STL implementation (actually Dinkumware one) says almost the same as your quoted SGI doc. They mean that they did nothing to make STL objects (e.g. containers) thread-safe, most probably because this would add an overhead unnecessary in many single-threaded applications. Any object is thread-safe in their terms, you can read it from multiple threads.

Also docs guarantee that STL objects are not modified under the hood in some background threads.

Answer 2

FWIW I updated the libstdc++ docs a while ago, it now says (emphasis mine):

The user code must guard against concurrent function calls which access any particular library object's state when one or more of those accesses modifies the state.

Answer 3

The information you cite is not contradictory. STL libraries should be safe to be used in a multi-threaded environment (actually, I've worked with one implementation where it was not the case) but it is users' burden to synchronize access to library objects. For instance, if you create a set of ints in one thread and another set of ints in another thread and you don't share either of them among threads, you should be able to use them; if you share an instance of a set among threads, it's up to you to synch the access to the set.