Doc. No.: | WG21/N2775 J16/08-0285 |
---|---|
Date: | 2008-9-18 |
Authors: | Hans-J. Boehm, Beman Dawes |
Phone: | +1-650-857-3406 |
Email: | Hans.Boehm@hp.com |
When N2669 (Thread-safety in the standard library) was voted into the working paper, there was a widespread sentiment that it was both a marked improvement and an incomplete solution. This is an attempt to address the most blatant remaining issues, and to thus move us closer to a complete solution.
Here we specifically address two issues:
Rewrite 17.6.4.10 [res.on.objects]:
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 [res.on.data.races].
The behavior of a program is undefined if calls to standard library functions from different threads:
share access to an object directly or indirectly via their arguments, including this, andat least one of the arguments accessing a shared object is non-const, andone call does not happen before the other (1.10).
[ 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. ]
Insert slight variant of original text before 17.6.5.6 [reentrancy], making it clear that this has nothing to do with threads:
Except where explicitly specified in this standard, it is implementation defined which functions in the C++ standard library may be recursively reentered.
In 17.6.5.6 [res.on.data.races], delete p15 on reentrancy:
C++ standard library functions shall be reentrant subroutines.
In 17.6.5.6 [res.on.data.races], insert after p18:
A C++ standard library function f shall not access objects indirectly accessable via its arguments or via elements of its container arguments, except by invoking functions, required by f's specification, on those container elements.