Submitter: Jens Gustedt
Submission Date:
2012-10-08
Source:
Reference Document: N/A
Version: 1.0
Date: 2012-10-08
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 to key set to a
value x that is not null, the destructor
function *dtor is called with dtor(x)
before the thread exits.
This call to dtor is executed in the context of the
same thread; it is sequenced after the return statement
or the call to thrd_exit that terminates the thread and
before any return from thrd_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 for key issues calls
to tss_set, tss_get
or tss_delete with the same key the
behavior is undefined.
tss_set can be used to set the value of a thread
specific storage for a different key key2 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
the return of the thread function or at the end
of thrd_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
by TSS_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 of key will not change the observable
behavior of any of the active threads. If tss_delete is
called for key and there is a thread that has a
non-null value for key that has passed a
terminating return statement or call
to thrd_exit but not yet finished the processing of all
its tss destructors, the behavior is undefined.