Possible Duplicate:
question about STL thread-safe and STL debugging
I'm currently being engaged in a project which is developed using C++. Recently we are considering replacing some self-defined thread-safe containers with some STL equivalents to gain some efficiency.
However, after looking for a while, I found that there is no a thread-safe container provided in STL at all, which surprises quite a lot. Is there any reason?
Probably because it wouldn't actually be all that useful (in addition to what @Luchian Grigore says in another answer). Even if individual container operations are thread-safe, you still need to do a lot of work to ensure thread safety. For instance, this simple code contains a race condition even if the container itself is thread-safe:
if (!container.empty())
container.pop();
Standard Library containers do provide some basic thread safety, Performance was a more important design goal for designers of the Standard Library containers than safety.
All Standard Library containers guarantee:
Multiple concurrent reads from the same container are safe but
If there is atleast one writer thread, then there is no thread safety & there shall not be any other writer or reader.
The Standard Library containers were primarily designed for working efficiently in Single threaded environments and providing only basic thread safety is a way to ensure full performance for containers that do not need concurrent access.
The basic thread safety needs that users need some sort of synchronization methods to avoid race conditions through use of using mutexes, or locks.Locking or other forms of synchronization are typically expensive and hence need to be avoided when not necessary.
Also, given the interfaces exposed by the Standard Library containers, It is easy for the client or user of the container to provide the necessary locking by wrapping the underlying container operations with a lock acquisition and release if intended use is for multi-threaded environments.
Note that All the implementations conform the following requirements specified by the C++ Standard:
17.6.3.10 Shared objects and the library [res.on.objects]
The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified in 17.6.4.8. [ Note: Modifying an object of a standard library type that is shared between threads risks undefined behavior unless objects of that type are explicitly specified as being sharable without data races or the user supplies a locking mechanism. —end note ]
Because thread safety is highly platform and compiler specific.
The C++ STL provides the kind of thread-safety that pretty much everything else provides: You can safely use STL containers from multiple threads so long as an object isn't accessed in one thread while another thread is, or might be, modifying it.
In a sentence - because it's hard.
Because thread-safe containers require specific design - e.g. they must be persistent data structures. Such containers are easiest to implement in functional / garbage collected / event-based environments. Which C++ is not.
That is to say, implementing these would still require the user to handle all resource allocation/deallocation. That kind of defeats the point of having a collection.
