Are STL Container Classes Of Same Type Thread Safe?

Question

I have a Vector A on Thread 1, I also have a Vector B on Thread 2.

Is it safe to write to vectors A and B at the same time, given they are different instantiated objects but of the same type?

If not, why is this different from the writing to an int c on Thread 1 and an int d on Thread 2?

Answer 1

Yes, it's safe. If thread 1 allocates vector A, and thread 2 allocates vector B, and neither knows anything about the other's vector instance, it will be safe. It won't be any different than accessing ints.

Now, if thread 1 and thread 2 are trying to access the same vector or int, that is not thread safe and you'll have to add synchronization.

Answer 2

STL containers are not Thread Safe. So you will have to implement your own synchronization mechanisms to use STL in a multithreaded environment.

Given the above, to answer your question:
It is safe to read and write to one instance of a type even if another thread is reading or writing to a different instance of the same type.
For example, given objects A and B of the same type(std::vector in your case), it is safe if A is being written in thread 1 and B is being read in thread 2.

Why is this different to writing to two ints on different threads?
It is just the same.
Just like you would not require any synchronization to writing to two separate integers in two different threads, You do not require any synchronization to write to two different vectors in two separate threads.

---

Here is the relevant citation from MSDN:

The following thread safety rules apply to all classes in the Standard C++ Library (except shared_ptr and iostream classes, as described below).

A single object is thread safe for reading from multiple threads.
For example: Given an object A, it is safe to read A from thread 1 and from thread 2 simultaneously.

If a single object is being written to by one thread, then all reads and writes to that object on the same or other threads must be protected.
For example: Given an object A, if thread 1 is writing to A, then thread 2 must be prevented from reading from or writing to A.

It is safe to read and write to one instance of a type even if another thread is reading or writing to a different instance of the same type.
For example: Given objects A and B of the same type, it is safe if A is being written in thread 1 and B is being read in thread 2.

Answer 3

References given relating to C++0x FDIS as C++03 did not mentionned threads at all.

First: yes, using two distinct containers (beware of aliasing through references/pointers) in two distinct threads is safe.

§ 17.6.5.9 Data race avoidance

2/ A C++ standard library function shall not directly or indirectly access objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s arguments, including this.

3/ A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this.

(further notes precise that if the implementation use shared states between different objects, access shall be protected appropriately so that it is invisible to the user)

Even more, accessing two differents objects within one container is safe!

§ 23.2.2 Container data races

2/ Notwithstanding (17.6.5.9), implementations are required to avoid data races when the contents of the contained object in different elements in the same sequence, excepting vector<bool>, are modified concurrently.

Also, even though C++98/C++03 did not address this question in the Standard, any quality implementation already conformed. If you are using either MSVC's or gcc's library, it already works, and it probably works for most of the other compilers' library too.

Answer 4

I highly expect all standard container implementations to be thread safe for unshared collections (i.e. distinct collections of the same type, like you put it).

But, to be precise, you'll HAVE to consult your library's documentation, as the standard doesn't address threading at all (c++11 makes some amendments there, but implementations are not widely on par with that)

The only edge case would be some string library implementation and especially io streams (mainly because of shared information like locale definitions, character sets and possibly sentries that could be lazily constructed; mainly the risk would be multiple threads constructing the same global data concurrently. The risk gets bigger when you actively manipulate and imbue locale facets).

Answer 5

None of standard container classes are thread-safe. If two different threads access the same member function which modifies the shared resource(s), then your code is not safe.

But in your code, vectorA and vectorB are not shared resources, then your code is safe, assuming that the vectors do not contain shared resources themselves.