|Anonymous | Login||2020-12-05 02:50 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000869||[1003.1(2013)/Issue7+TC1] System Interfaces||Editorial||Clarification Requested||2014-08-25 17:37||2014-10-02 15:28|
|Section||sem_destroy, sem_wait, sem_post|
|Final Accepted Text|
|Summary||0000869: Concept of being "blocked" on a semaphore is not defined but needed for sem_destroy rules|
The specification of sem_wait does not use the term "block" or "blocked" at all, but sem_destroy is specified to be defined only when no threads are "currently blocked" on the semaphore. This gap leaves it unclear to applications when it is actually permissible to destroy a semaphore.
My current understanding of the intent is that sem_wait on a semaphore which is currently locked causes the calling thread to be "blocked" on the semaphore, and that the state of being "blocked" ends at an indeterminate time between being interrupted by a signal handler, timing out (in the case of timedwait), or the semaphore being posted, and the actual return from the sem_wait (or timedwait) function. I base this interpretation on:
1. The fact that the specification for sem_post does not say that it "unblocks" a waiter, only that "one of the threads blocked waiting for the semaphore shall be allowed to return successfully from its call to sem_wait"; this is in contrast to the explicit "shall unblock" language in the specification of pthread_cond_signal.
2. Since sem_post is specified to be async-signal-safe, it seems unreasonable to require it to perform any synchronization with a waiting thread that would be necessary to ensure that the waiting thread is "unblocked" before sem_post returns. (For example, the waiting thread could be the same thread, and sem_post could be called from a signal handler that interrupted sem_wait.)
3. Unlike with condition variables (where the atomicity with unlocking the mutex makes it possible to observe which threads have blocked), there is no way to observe that a thread has already blocked on a semaphore. The state of being delayed pending scheduling prior to entry into the sem_wait function, and of having entered sem_wait and blocking on the semaphore, are indistinguishable. Therefore, it seems impossible to observe a violation of a potential requirement that sem_post actually "unblock" a thread, and thus, unreasonable to impose such a requirement.
Under this interpretation, destruction is only permissible after all threads blocked in sem_wait actually return from the call, not immediately after sufficiently many posts have been performed to allow all such threads to unblock.
In the description of sem_wait, at the end of the paragraph:
"The sem_wait() function shall lock the semaphore referenced by sem by performing a semaphore lock operation on that semaphore. If the semaphore value is currently zero, then the calling thread shall not return from the call to sem_wait() until it either locks the semaphore or the call is interrupted by a signal."
Add the following text:
"In this case, the calling thread shall be considered blocked on the semaphore until it ether returns from the sem_wait call or acts upon cancellation."
|Tags||No tags attached.|
|XBD 3.76 defines a Blocked Process (or Thread) as "A process (or thread) that is waiting for some condition (other than the availability of a processor) to be satisfied before it can continue execution." By this definition, the thread is blocked by sem_wait(). Adding additional language here does not clarify the situation.|
|2014-08-25 17:37||dalias||New Issue|
|2014-08-25 17:37||dalias||Name||=> Rich Felker|
|2014-08-25 17:37||dalias||Organization||=> musl libc|
|2014-08-25 17:37||dalias||Section||=> sem_destroy, sem_wait, sem_post|
|2014-08-25 17:37||dalias||Page Number||=> unknown|
|2014-08-25 17:37||dalias||Line Number||=> unknown|
|2014-10-02 15:28||nick||Interp Status||=> ---|
|2014-10-02 15:28||nick||Note Added: 0002398|
|2014-10-02 15:28||nick||Status||New => Resolved|
|2014-10-02 15:28||nick||Resolution||Open => Rejected|
|2014-10-02 15:28||nick||Page Number||unknown => 1829|
|2014-10-02 15:28||nick||Line Number||unknown => 58909|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|