This document deals with various aspects of data races related
to shared global state. It is related to papers N2226, N2227,
N2228, but the changes discussed here either lack implementation
affect a function widely considered obsolescent
In 188.8.131.52 (The
strtok function) it is mentioned that:
strtokfunction is not required to avoid data races with other calls to the strtok function.
An implementation which would like to support applications which
strtok in the presence of threads will face
substantial challenges in doing so. The reason is that the
standard currently requires that the
internal state is shared among all threads, and an application
can observe this by calling
strtok from several
threads with proper synchronization. (The data races cannot be
avoided by using atomic operations inside
alone because the buffer is written to
strtok and read outside of it, and the read
access is not atomic.)
The Solaris implementation of
strtok appears to be
non-conforming because it is implemented with thread-local state:
strtok()function is safe to use in multithreaded applications because it saves its internal state in a thread-specific data area. [Source]
POSIX suggests the possibility of a thread-safe
implementation of the function, but does not discuss that
strictly conforming programs are able to detect that the
hidden internal state has thread storage duration, by
strtok function from separate
threads with suitable external synchronization.
Rather than coming up with language that covers all existing
implementation behavior, we propose to make
strtok function undefined in multi-threaded
programs. This is the approach already used for the
getenv function in 184.108.40.206, it is not
entirely clear how an implementation would eliminate the
data race. One approach would be to make sure that the
returned pointer remains valid until the current thread
exits, so the proposal suggests to support this approach.
POSIX suggests that a thread-safe implementation of
getenv function is possible, but does not
say how, and suggests that in the future, separate
interfaces might be provided for that.
In the case of the
function defined in Annex K, implementations should be able
to make the current handler state thread-local if they
desire to do so, as long as the handler state is inherited
from the current thread at the time of creation.
If Annex K is deprecated (see
then this proposal can be dropped, or a solution similar
strtok (undefined behavior in multi-threaded
programs) could be adopted.
In J.2 (Undefined behavior), add:
The strtok function is not required to avoid data races with other calls to the311)
strtok_sfunction can be used instead
to avoid data races.
The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to theIn J.2 (Undefined behavior), add:
Only the most recent handler registered withIn J.3.12 (Library functions), add:
set_constraint_handler_sis called when a runtime-constraint violation occurs.