§7.26.1 Introduction specifies the following:
-1- The header <threads.h> includes the header <time.h>, defines macros, and declares types, enumeration constants, and functions that support multiple threads of execution.
…
-4- The types are:
……
- mtx_t
- which is a complete object type that holds an identifier for a mutex;
One of the questions raised by DR 493 is the following:
Since mtx_t is a complete object type, what are the semantics of copying objects of the type (either by assignment or by passing them by value between functions) and passing pointers to distinct copies of the same mutex object as arguments to the C11 threads functions?
The committee's response is that:
The semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6.
This isn't a sufficient or correct response.
First, the semantics of copying a FILE objects aren't unspecified because FILE need not be a complete type (i.e., FILE objects simply cannot be copied by strictly conforming programs).
Second, the informative section §J.1 Unspecified behavior that collects references to instances of unspecified behavior in the rest of the text contains no references to §7.26. (Nor does the section mention the semantics of copying FILE objects because there are none.)
Finally, since unlike FILE, a possibly incomplete object type, mtx_t is a complete object type, strictly conforming programs can make copies of mtx_t objects. The semantics of creating or using such copies aren't explicitly spelled out anywhere but in the absence of any text to the contrary it is reasonable to assume that they are the same as those for any other complete object type, either one specified by the standard (e.g., struct timespec) or one defined by a program.
However, in typical implementations, mtx_t need not, and in fact, in the canonical Pthreads-based implementations cannot, be copied because it contains an object of the non-copyable pthread_mutex_t type. POSIX specifies in <sys/types.h> of the XBD section that:
There are no defined comparison or assignment operators for the following types:
- pthread_attr_t
- pthread_barrier_t
- pthread_barrierattr_t
- pthread_cond_t
- pthread_condattr_t
- pthread_mutex_t
- pthread_mutexattr_t
- pthread_rwlock_t
- pthread_rwlockattr_t
- pthread_spinlock_t
- timer_t
This also implies that the semantics of copying pthread_mutex_t objects or using them in threads functions are undefined in POSIX and not unspecified. (E.g., a call to pthread_mutex_unlock on a copy of a pthread_mutex_t object object can crash or result in other kinds of incorrect/undefined behavior.)
In order to permit Pthreads-based implementations of the threads library C needs to specify a similar constraint.
The committee response appears to miss this point and so it should be corrected.
Modify §7.26.1 Introduction as follows:
-4- The types are:
……
- mtx_t
- which is a complete object type that holds an identifier for a mutex; the effects of copying mtx_t objects are undefined;
In addition, add a bullet to §J.2 Undefined behavior referencing the undefined behavior that results from copying mtx_t objects..