This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.

1095. Shared objects and the library wording unclear

Section: 16.4.5.10 [res.on.objects] Status: C++11 Submitter: Beman Dawes Opened: 2009-03-27 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [res.on.objects].

View all issues with C++11 status.

Discussion:

N2775, Small library thread-safety revisions, among other changes, removed a note from 16.4.5.10 [res.on.objects] that read:

[Note: This prohibition against concurrent non-const access means that modifying an object of a standard library type shared between threads without using a locking mechanism may result in a data race. --end note.]

That resulted in wording which is technically correct but can only be understood by reading the lengthy and complex 16.4.6.10 [res.on.data.races] Data race avoidance. This has the effect of making 16.4.5.10 [res.on.objects] unclear, and has already resulted in a query to the LWG reflector. See c++std-lib-23194.

[ Batavia (2009-05): ]

The proposed wording seems to need a bit of tweaking ("really bad idea" isn't quite up to standardese). We would like feedback as to whether the original Note's removal was intentional.

Change the phrase "is a really bad idea" to "risks undefined behavior" and move to Review status.

[ 2009-10 Santa Cruz: ]

Note: Change to read: "Modifying...", Delete 'thus', move to Ready

Proposed resolution:

Change 16.4.5.10 [res.on.objects] as indicated:

The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified in 17.6.4.7.

[Note: Modifying an object of a standard library type shared between threads risks undefined behavior unless objects of the type are explicitly specified as being sharable without data races or the user supplies a locking mechanism. --end note]