Defect Report #424

Submitter: Jens Gustedt
Submission Date: 2012-10-08
Source: WG14
Reference Document: N1651
Version: 1.3
Date: October 2014
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

• what a destructor should be,
• when such a destructor should be called,
• in which thread context this constructor is executed
• what happens when new destructors are added while others are executed
• what the meaning of the value of 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.

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 of thrd_exit and tss_delete.

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