Submitter: Jens Gustedt
Submission Date:
2012-10-08
Source: WG14
Reference Document:
N1651
Version: 1.1
Date: April 2013
Subject: underspecification of tss_t
Summary
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 pthread_key_t
that is completely
feature equivalent and for which the specification is much more
complete.
Jacob Navia had observed that at several occasions
in comp.std.c
but it seems that he had not got enough
attention such that this had made it in a defect report.
The tss_create
function creates a thread-specific
storage pointer with destructor dtor
, which may be
null.
The main problem is that it is nowhere explained/defined
TSS_DTOR_ITERATIONS
would be.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 tokey
set to a valuex
that is not null, the destructor function*dtor
is called withdtor(x)
before the thread exits.
This call todtor
is executed in the context of the same thread; it is sequenced after thereturn
statement or the call tothrd_exit
that terminates the thread and before any return fromthrd_join
of 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 forkey
issues calls totss_set
,tss_get
ortss_delete
with the samekey
the behavior is undefined.
tss_set
can be used to set the value of a thread specific storage for a different keykey2
that 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 thereturn
of the thread function or at the end ofthrd_exit
there are still tss that are active the procedure of calling destructors is iterated. An implementation may bind the maximum number such of supplementary iterations byTSS_DTOR_ITERATIONS
.
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,
and tss_delete
that deletes a thread specific storage
for all running threads. I think something like the following should
be added in 7.26.6.2 after para 2:
The deletion ofkey
will not change the observable behavior of any of the active threads. Iftss_delete
is called forkey
and there is a thread that has a non-null value forkey
that has passed a terminatingreturn
statement or call tothrd_exit
but not yet finished the processing of all its tss destructors, the behavior is undefined.
Committee Discussion
These issues are covered under DR 416. See discussion there.Apr 2013 meeting
Committee Discussion
In addition to DR 416 this report suggests defining as undefined behavior the interaction ofthrd_exit
andtss_delete
.