|Reply to:||Hans-J. Boehm|
This is an attempt to distill some relatively small and hopefully relatively uncontroversial improvements from a more heated discussion of the C threads API. The earlier discussion involved several Austin Group members, notably David Butenhof, as well as Jim Thomas. Both David Butenhof and Jim Thomas also provided useful comments on an earlier version of this document.
We primarily address three largely independent issues: The separate initialization option to support mtx_trylock, lifetime of thrd_t values, and miscellaneous clarifications of the interaction of the API with the memory model.
We conclude with a short list of open threads issues that still require attention. One of these, the interaction of stdio, is unfortunately nontrivial.
Remove the mtx_try entry from 7.25.1, the <threads.h> description.
Remove all lines in 184.108.40.206p2 that mention mtx_try.
Remove the following sentence from 220.127.116.11p2:
The mutex pointed to by mtx shall be of type mtx_try, mtx_try | mtx_recursive, mtx_timed, or mtx_timed | mtx_recursive.
Remove mtx_try from B.24, the identifies defined in threads.h.
I believe there is an increasing consensus that the Posix approach is needlessly error prone. For example, when signaling a detached thread, there is a danger that the thread already exited, and its id has been reused by another thread.
However, since I view the C threads API as a thin veneer on the underlying thread library, and I would be opposed to a C threads API that did anything else, I believe compatibility with interfaces like Posix trump other considerations in this case. In addition the C threads API is narrow enough that I expect the problem cases to arise much more rarely. Thus I propose to make it clear that we are pursuing option 2.
If the committee disagrees, I believe an explicit clarification would still be called for.
In 18.104.22.168, change
... it sets the thread thr to a value that uniquely identifies the newly created thread.
... it sets the thread thr to a value that uniquely identifies the newly created thread. The same thr value may be reused and become associated with a different thread after both (1) the newly created thread exits and (2) the thr value has been set by a call to thr_join or detach.(The wording with respect to thr_join or detach was copied from elsewhere. I'm not sure this is the best way to state this.)
In 22.214.171.124p2 and 126.96.36.199p2 (mtx_timedlock/mtx_trylock), replace
Prior calls to mtx_unlock on the same mutex shall synchronize with this operation.
If the operation succeeds, prior calls to mtx_unlock on the same mutex shall synchronize with this operation.
In 188.8.131.52p2, add to the description of thrd_create either:
The completion of the thrd_create call synchronizes with the beginning of the execution of func(arg).
The thrd_create call performs an action a that synchronizes with the beginning of the execution of func(arg). The action a need not be sequenced after the setting of thr.
The former requires would imply that the stored thread value is visible immediately to the child thread. The thread cannot be started until it is stored. The latter formulation avoids this requirement. It appears that Posix does not impose this requirement, though that may have been an accident. The first formulation may require minor implementation changes in the underlying thread library, but is slightly friendlier to programmers.
In 184.108.40.206p2, add to the description of thrd_join:
The termination of the thread synchronizes with the thrd_join call.
Here are a few more threads-related issues that probably require attention, but for which we are not yet proposing wording: