Stl Vector and Thread-Safety

Are std::vectors threadsafe?

If you have setup the vector before entering into multi-threading scenario, and then you want to only read the vector from multiple threads, without modifying it, then it is thread-safe. You can read even the same element from more than two threads simultaneously, just make sure that no thread modifies the vector in any way. Treat the vector and all its elements as read-only.

However, for modification, none of the containers from the Standard Library are thread-safe. You need to implement the synchronization yourself.

C++11 has introduced many synchronization primitives, so if your compiler supports, you can use them.

Is std::vector thread-safe and concurrent by default? Why or why not?

C++11 says the following about the thread safetly of containers in the standard library:

23.2.2 Container data races [container.requirements.dataraces]

For purposes of avoiding data races (17.6.5.9), implementations shall
consider the following functions to be const: begin, end,
rbegin, rend, front, back, data, find, lower_bound,
upper_bound, equal_range, at and, except in associative or
unordered associative containers, operator[].

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.

So, basically reading from a container from multiple threads is fine, and modifying elements that are already in the container is fine (as long as they are different elements).

So, neither of your two more specific questions are thread safe for std::vector:

1) Two threads inserting into the vector is modifying the vector itself - not existing separate elements.

2) One thread erasing and other walking to access the same element is not safe because erasing an element from the vector isn't an operation that is promised to be thread safe (or "free from data races", as the standard puts it).

To perform those operations safely will require that the program impose some external synchronization itself.

Is stl vector concurrent read thread-safe?

YES for the scenario you mention, it is perfectly Thread Safe.

Actually, STL is not a correct way of referring it.

It is the C++ Standard Library.

The C++03 Standard does not talk about concurrency at all, So the concurrency aspect is left out as an implementation detail for compilers. So the documentation that comes with your compiler is where one should look to for answers related to concurrency.

Most of the STL implementations are not thread safe as such.

But for concurrent reads of same object from multiple threads most implementations of STL are indeed thread safe.

References:

MSDN says:

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.

The Dinkumware STL-Documentation says:

Multiple threads can safely read the same container object. (There are nunprotected mutable subobjects within a container object.)

GCC Documentation says:

We currently use the SGI STL definition of thread safety, which states:

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.

So from the above, Yes it is thread safe in GCC to have concurrent reads of same object from multiple threads.

Note: GCC's Standard Library is a derivative of SGI's STL code.

STL vector and thread-safety

I want to ask whether a problem may occur during reallocating of vector to a larger memory block, if there are some child working threads left from the previous update.

Yes, this would be very bad.

If you are using a container from multiple threads and at least one thread may perform some action that may modify the state of the container, access to the container must be synchronized.

In the case of std::vector, anything that changes its size (notably, insertions and erasures) change its state, even if a reallocation is not required (any insertion or erasure requires std::vector's internal size bookkeeping data to be updated).

One solution to your problem would be to have the producer dynamically allocate the std::vector and use a std::shared_ptr<std::vector<T> > to own it and give this std::shared_ptr to each of the consumers.

When the producer needs to add more data, it can dynamically allocate a new std::vector with a new, larger size and copies of the elements from the old std::vector. Then, when you spin off new consumers or update consumers with the new data, you simply need to give them a std::shared_ptr to the new std::vector.

Is assignment to a std::vector element thread-safe?

Assuming your global vector is not modified by any other part of code, then your code is thread safe.

Each thread is going to write (access) into a different cell of the vector, so there is no "dirty update" problem.

Moreover the vector's type is a double, in a modern architecture is bigger than a WORD-size. So each array cell is not overlapped among others.

C++11 / C++03 and std::vector thread safety

It is meaningless to ask whether something is thread-safe under the C++03 standard - C++03 and earlier didn't have any concept of threads or thread safety.

ChangeValue is data race-free (as defined by C++11 and later) as long as no two threads pass the same argument for index, or else calls passing the same argument are synchronized with each other by some means external to the function.