Is stl vector concurrent read thread-safe?

Question

I am working on a application where huge number of threads are expected to iterate over set of string values and try to match it's own data with the data available in the list.

I am looking for following use case:

1. Vector is initialized with few elements of type std::string. (Lets say object name is strList). strList will get initialized at the time of application startup.
2. All threads will iterate over strList to see if it's value matches with atleast one element of strList.
3. No thread will ever try to modify strList and it will be strictly used as readonly object.

So could you please tell me if concurrent reads are thread-safe on vector object. I am using RHEL 6 and gcc version is 4.5.x

Answer 1

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.

Answer 2

There is a specific mention in the C++0x FDIS (n3290) for this.

§ 17.6.5.9 Data race avoidance

The whole paragraph is of interest but more particularly:

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.

means that you may call cbegin and cend on std::vector<T> safely. As well as calling operator== or operator< on std::string.

6/ Operations on iterators obtained by calling a standard library container or string member function may access the underlying container, but shall not modify it.

means that merely iterating over a container should not modify the said container in any way.

Despite 3/ though, there seems to be room for global objects though, as iterators modifying some kind of shared register object in which they would associate themselves with the container (STL debug features). I don't make sense of:

7/ Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races.

otherwise.

Anyway, the Standard guarantees that iterating over the vector will be safe... but makes no guarantees when it comes to actually reading the objects (those are your own). In this case, this is covered because std::string is covered above.

EDIT: As David Hammen justly noted, this Standard is not yet fully implemented. Many compilers already provided the guarantees above, even though the previous Standard never spoke about threads. MSVC, gcc, clang, icc, comeau, etc... All big names should already provide this guarantee, as can be seen from Als' answer.

Answer 3

In addition to the generic rules about data race avoidance, in [container.requirements.dataraces] the standard says

-1- 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[].

So even if you call the non-const begin()/end() etc. as long as you don't actually modify anything it's safe.