Std::Vector, Thread-Safety, Multi-Threading

C++ thread safe vector insertion

There must be only one mutex for the vector. So you should add the mutex next to the vector, e.g. as results_mutex in Resources. If results is a static member then the mutex should be a static member as well (so that there is only one mutex for the vector).

Then you must also lock the mutex on all operations accessing the vector that could potentially be executed in parallel with a call to insert_output, not only on the insert operation.

In your current code you create a new mutex on each call, making it completely pointless.

std::vector, thread-safety, multi-threading

Actually, it is absolutely pointless to state X is or is not thread-safe! You need to qualify for what kind of uses. For example, hardly any class will be "thread-safe" when it is somehow used in one thread and destroyed in another.

That said, the statement that std::vector<T> is not thread- safe, independent of how often it is repeated, is wrong. However, it seems most people neither understand nor appreciate the thread-safety guarantees given. std::vector<T> is thread-safe in the following sense:

You can read a vector object from multiple threads simultaneously.
If there is one thread changing a vector object, there shall be neither concurrent readers or writers.
Accesses to a vector object don't interfere with other vector objects.

This applies to vector structure itself. Accesses to contained object are bound to whatever rules are imposed on them. These are apparently not the thread-safety guarantees many people have in mind but anything stronger won't work with the container interface.

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.

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 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.