Concurrency with const std::T's

Question

As an example, consider a std::map implemented with a Splay tree. This kind of tree structure is mutable and changes every time the map is accessed for reading. When the map is const, who must garantuee the isolation of concurrent readings, is it up to the user code or to the map implementation?

I don't think the standard makes any statement about concurrency of containers. — Oliver Charlesworth, Mar 07 '12 at 09:02
this is a sort-of duplicate of this question: http://stackoverflow.com/questions/1846186/thread-safety-of-stdmap-for-read-only-operations — CashCow, Mar 07 '12 at 09:06
Are concurrent accesses to *different* map objects thread-safe? — Martin, Mar 07 '12 at 09:14
Martin, yes, they are unless you have map> in which case the outer-map and inner-map are related. — CashCow, Mar 07 '12 at 09:18
23.2.2 _"For purposes of avoiding data races (17.6.4.8), 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[]"_. If I read this correctly, it is not legitimate to use a splay tree as an underlying structure at all, since e.g. `find` is not `const`. — Damon, Mar 07 '12 at 09:44

score 4 · Accepted Answer · edited May 23 '17 at 12:03

The questioner knows that if you have threads that write to a collection, the user must manage the synchronised locking.

The question seems to be whether the standard can guarantee thread-safety if simulataneous threads are only reading the collection.

I am not sure that the old C++ standards had any guarantees of thread-safety with any operations at all, but the new one will (section has been given in comments, 23.2.2). As it is, most vendors now do guarantee thread-safety amongst concurrent reads, notwithstanding the fact that the concurrency within the objects contained in the collection obviously need to be handled by the user.

In the same way, you would be able to use read-write locks on an STL collection.

These are related question on stack overflow:

Thread safety of std::map for read-only operations

Is the C++ std::set thread-safe?

score 0 · Answer 2 · edited May 23 '17 at 11:55

0

read the topic below:

seems similar to me with what you are asking:

Thread safety of std::map for read-only operations

edited May 23 '17 at 11:55

Community

1
1

answered Mar 07 '12 at 09:03

Stefan Birladeanu

294
2
10

score -1 · Answer 3 · edited Mar 07 '12 at 09:26

-1

std::* does not guarantee any thread safety.

edited Mar 07 '12 at 09:26

graham.reeds

16,230
17
74
137

answered Mar 07 '12 at 09:02

triclosan

5,578
6
26
50

Actually section 23.2.2 of C++11 defines the data race guarantees on standard containers. – edA-qa mort-ora-y Mar 07 '12 at 09:18

Concurrency with const std::T's

3 Answers3