0

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.

codeLover
  • 3,720
  • 10
  • 65
  • 121
  • 7
    No, they are not thread safe. What if the container is modified by another thread while you're doing your operations? – Some programmer dude Jul 17 '17 at 09:50
  • 1
    If nothing changes the data you will be fine. – doctorlove Jul 17 '17 at 09:51
  • 1
    http://en.cppreference.com/w/cpp/container – Holt Jul 17 '17 at 09:51
  • 4
    You need to ask questions about thread safety with respect to 2 or more threads and detail what these threads could be doing simultaneously. As the questions stands we do not have enough information to answer you. – Richard Critten Jul 17 '17 at 09:51
  • what are you concerned about when there are only reads? Threadsafety is an issue when you have reads and writes – 463035818_is_not_an_ai Jul 17 '17 at 09:52
  • 1. Use const iterators if you just intent to read. 2. This is not safe - other threads can modify those vectors in any of the various ways that invalidate iterators which would lead to UB when you try to use them – K. Kirsz Jul 17 '17 at 09:53
  • If all the threads that shares the container performs ONLY READ operations there are no problems. [This post](https://stackoverflow.com/questions/7455982/is-stl-vector-concurrent-read-thread-safe) should clarify – Simone Cifani Jul 17 '17 at 09:54

5 Answers5

4

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

freakish
  • 54,167
  • 9
  • 132
  • 169
4

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.

eerorika
  • 232,697
  • 12
  • 197
  • 326
1

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.

463035818_is_not_an_ai
  • 109,796
  • 11
  • 89
  • 185
1

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.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
0

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.

Mike Lischke
  • 48,925
  • 16
  • 119
  • 181