CODEWITHSUNDEEP
c++multithreadingc++11thread-safetymutex
codeLover
codeLover

Reputation: 3810

Thread safety of the non-write member functions of vectors and lists in C++

If I'm accessing the member functions of the std::vector or std::list, it is threadsafe ?

Example:

struct ABC
{
...
}

std::vector<ABC> vecofAbc;

Are the following operations threadsafe as they are just read ?

vecofAbc.at(1) ;
ABC::iterator iter = vecofAbc.end();
ABC::iterator iter = vecofAbc.begin();

Similiarly are the above member function for std::list thread safe ?

I know push_back() would not be a threadsafe as it's write.

Upvotes: 0

Views: 250

Answers (5)

Yakk - Adam Nevraumont
Yakk - Adam Nevraumont

Reputation: 275385

It is best to think of thread safe in C++ not as a property of a single operation, but of a property of multiple operations relative to each other.

vecofAbc.at(1) ;
ABC::iterator iter = vecofAbc.end();
ABC::iterator iter = vecofAbc.begin();

each of these is mutually thread safe. They can occur in seperate threads with no data races involved.

There are operations which are not mutually thread safe with the above operations. These include

vecofAbc.push_back(some_abc);
vecofAbc.reserve(10000);

also note that

vecofAbc[0] = some_abc;

is mutually thread safe with

vecofAbc.at(1);

or

vecofAbc[1] = some_abc;

The rule is that any number of const operations on a container are mutualy threads safe, and that .begin(), end() and a number of other operations (which do not mutate container layout) are treated as const as far as this rule is concerned.

In addition, reading from/writing to an element is mutually thread safe with reading/writing from distinct elements, and reading from/writing to an element is mutually thread safe with other const operations on the container (and other operations which are treated as const by the above rule).

std::vector guarantees it will only call const methods on classes when itself is being called through const methods or through methods treated as const under the above rule. If your object's const methods fail to be mutually thread safe, all bets are off.

See Does const mean thread safe for more details.

Upvotes: 1

eerorika
eerorika

Reputation: 238311

Read operations are not thread safe. If the container is modified while a read operation is being executed, then there is a data race, and the behaviour is undefined.

Read operations do not create race coditions by themselves, so multiple reads do not need to be synchronized in relation to each other - only in relation to modifications.

Upvotes: 4

463035818_is_not_an_ai
463035818_is_not_an_ai

Reputation: 122238

A method is said to be thread safe when it is not affected by other threads reading or writing the same data concurrently. So the fact that you do only reads is actually irrelevant. The methods you mention are not thread safe, because if there was a second thread modifing the vector concurrently you would have a data race.

PS: Nevertheless, if you do only read from the vector you dont need threadsafety, as there are no data-races and everthing is fine.

Upvotes: 1

Mike Lischke
Mike Lischke

Reputation: 53315

If you can guarantee that there is only read access to this vector then yes, it's safe to do that from multiple threads. Trouble comes up only when something is changed by a thread.

Upvotes: 0

freakish
freakish

Reputation: 56467

Reads are thread safe and don't need synchronization mechanisms as long as there are no parallel writes.

Upvotes: 4

Related Questions