C ++ STL对不同的容器是否是线程安全的（使用STLport实现）？

Question

I'm using Android 2.2, which comes with a version of STLport. For some reason, it was configured to be non-thread safe. This was done using a #define _NOTHREADS in a configuration header file.

When I constructed and initialized distinct non-shared containers (eg strings) from different pthreads, I was getting memory corruption.

With _NOTHREADS, it looks like some low-level code in STL inside allocator.cpp doesn't do proper locking. It seems analogous to C not providing thread safety for malloc.

Does anyone know why STL might be built with _NOTHREADS by default on Android? By turning this off, I'm wondering if there may be a side effect. One thing I can think of is slightly degraded performance, but I don't see much of a choice given I'm using lots of threading.

Answer 1

The SGI STL

The SGI STL is the grandmother of all of the other STL implementations.

See the SGI STL docs .

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.

G++

libstdc++ docs

We currently use the SGI STL definition of thread safety.

STLPort

STLPort docs

Please refer to SGI site for detailed document on thread safety. Basic points are:

• simultaneous read access to the same container from within separate threads is safe;
• simultaneous access to distinct containers (not shared between threads) is safe;
• user must provide synchronization for all accesses if any thread may modify shared container.

Answer 2

General Information about the C++ Standard

The current C++ standard doesn't address concurrency issues at all, so at least for now there's no requirement that applies to all implementations.

A meaningful answer can only really apply to a specific implementation (STLPort, in this case). STLPort is basically a version of the original SGI STL implementation with improvements to its portability, so you'd probably want to start with the documentation about thread safety in the original SGI version.

Answer 3

Of course, the reason it is without re-entrancy is for performance: speed, less memory use, less resource uses. Presumably this is because the assumption is most client programs won't be multi-threaded.

Answer 4

Sun WorkShop 5.0

This is a bit old but quite informative. The bottom line is that STL only provides locks on allocators.

Strings however are referenced counted objects but any changes to their reference count is done atomically. This is only true however when passing strings around by value. Two threads holding the same reference to a single string object will need to do their own locking.

Answer 5

When you use eg std::string or similar objects, and change them from different threads, you are sharing same object between threads. To make any of the member functions you can call on string reentrant, it would mean that no other thread can affect our mem-function, and our function cannot affect any other calls in other threads. The truth is exactly the opposite, since you are sharing the same object via this pointer, which is implicitly given when calling member objects. To illustrate, equivalent to this call

std::string a;
a.insert( ... );

without using OOP syntax would be:

std::string a;
insert( &a, ... );

So, you are implicitly violating requirement that no resource is shared between function calls. You can see more here .

Hope this helps.