Submitter: Jens Gustedt
Submission Date: 2012-10-08
Reference Document: N1651
Date: October 2014
Subject: underspecification of
Section 7.26.6 “Thread-specific storage functions” of C11 is
severely underspecified since it uses terms that are not introduced (so
far) in the context of C. This is really a pity, since POSIX also has
that is completely feature equivalent and for which the specification
is much more complete.
Jacob Navia had observed that at several occasions in
but it seems that he had not got enough attention such that this had
made it in a defect report.
tss_create function creates a
thread-specific storage pointer with destructor
which may be null.
The main problem is that it is nowhere explained/defined
Suggested Technical Corrigendum
I think several paragraphs should be added after the one above:
The effect is that for each thread that has the thread specific storage corresponding to
keyset to a value
xthat is not null, the destructor function
*dtoris called with
dtor(x)before the thread exits.
This call to
dtoris executed in the context of the same thread; it is sequenced after the
returnstatement or the call to
thrd_exitthat terminates the thread and before any return from
thrd_joinof a waiter for this same thread. If there are several thread specific storages for the same thread their destructor functions are called in an unspecific order but with a sequence point between each of these function calls.
If a destructor function for
keyissues calls to
tss_deletewith the same
keythe behavior is undefined.
tss_setcan be used to set the value of a thread specific storage for a different key
key2that had not been set before or that has been processed with a call to the corresponding destructor.
By that the set of thread specific storages for a given thread may change during the execution of the corresponding destructors.
If after processing all tss that are active at the
returnof the thread function or at the end of
thrd_exitthere are still tss that are active the procedure of calling destructors is iterated. An implementation may bind the maximum number such of supplementary iterations by
A second problem is that there are two functionalities that are
easily mixed up and which interrelationship should be clarified: the
destructor that is called (let us suppose this) at exit of a thread,
tss_delete that deletes a thread specific storage for
all running threads. I think something like the following should be
added in 126.96.36.199 after para 2:
The deletion of
keywill not change the observable behavior of any of the active threads. If
tss_deleteis called for
keyand there is a thread that has a non-null value for
keythat has passed a terminating
returnstatement or call to
thrd_exitbut not yet finished the processing of all its tss destructors, the behavior is undefined.
These issues are covered under DR 416. See discussion there.
Apr 2013 meeting
In addition to DR 416 this report suggests defining as undefined behavior the interaction ofOct 2013 meeting
Proposed Committee Response
The issues raised herein have been considered in conjunction with DR 416 and are jointly resolved in that DR's Proposed Technical Corrigendum.
Previous Defect Report < - > Next Defect Report