|Hans-J. Boehm, Beman Dawes
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 22.214.171.124 [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, and
at least one of the arguments accessing a shared object is non-const, and
one 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 126.96.36.199 [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 188.8.131.52 [res.on.data.races], delete p15 on reentrancy:
C++ standard library functions shall be reentrant subroutines.
In 184.108.40.206 [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.