This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.
Section: 16.4.5.10[res.on.objects]Status:C++11Submitter: Beman DawesOpened: 2009-03-27Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [res.on.objects].
View all issues withC++11 status.
Discussion:
N2775,Small library thread-safety revisions, among other changes, removed a note from16.4.5.10[res.on.objects] that read:
[Note: This prohibition against concurrent non-const access means thatmodifying an object of a standard library type shared between threadswithout using a locking mechanism may result in a data race.--end note.]
That resulted in wording which is technically correct but can only beunderstood by reading the lengthy and complex 16.4.6.10[res.on.data.races]Data race avoidance. This has the effect of making16.4.5.10[res.on.objects] unclear, and has already resulted in a queryto 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 feedbackas to whether the original Note's removal was intentional.
Change the phrase "is a really bad idea"to "risks undefined behavior" andmove 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 libraryfunctions from different threads may introduce a data race. Theconditions under which this may occur are specified in 17.6.4.7.
[Note: Modifying an object of a standard library type shared betweenthreads risks undefined behavior unless objects of the type are explicitlyspecified as being sharable without data races or the user supplies alocking mechanism.--end note]