Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Resolved  
Name Rich Felker
Organization musl libc
User Reference
Section sem_destroy, sem_wait, sem_post
Page Number 1829
Line Number 58909
Interp Status ---
Final Accepted Text
Summary 0000869: Concept of being "blocked" on a semaphore is not defined but needed for sem_destroy rules
Description 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.
Desired Action 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.
Attached Files

- Relationships

-  Notes
nick (manager)
2014-10-02 15:28

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker