CODEWITHSUNDEEP
c++stlthread-safety
Ravi
Ravi

Reputation: 3766

Is C++ STL thread-safe for distinct containers (using STLport implementation)?

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 (e.g. 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.

Upvotes: 10

Views: 1567

Answers (5)

Yttrill
Yttrill

Reputation: 4931

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.

Upvotes: 1

Ken Bloom
Ken Bloom

Reputation: 58810

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.

Upvotes: 5

Jerry Coffin
Jerry Coffin

Reputation: 490808

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.

Upvotes: 2

LavaScornedOven
LavaScornedOven

Reputation: 747

When you use e.g. 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.

Upvotes: 0

doron
doron

Reputation: 28932

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.

Upvotes: 0

Related Questions