Austin Group Bug Tracker
2014-08-25 17:31:45 UTC
The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=868
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 868
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: sem_destroy, sem_wait, sem_post
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-25 17:31 UTC
Last Modified: 2014-08-25 17:31 UTC
======================================================================
Summary: 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.)
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."
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2014-08-25 17:31 dalias New Issue
2014-08-25 17:31 dalias Name => Rich Felker
2014-08-25 17:31 dalias Organization => musl libc
2014-08-25 17:31 dalias Section => sem_destroy,
sem_wait, sem_post
2014-08-25 17:31 dalias Page Number => unknown
2014-08-25 17:31 dalias Line Number => unknown
======================================================================
======================================================================
http://austingroupbugs.net/view.php?id=868
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 868
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: sem_destroy, sem_wait, sem_post
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-25 17:31 UTC
Last Modified: 2014-08-25 17:31 UTC
======================================================================
Summary: 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.)
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."
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2014-08-25 17:31 dalias New Issue
2014-08-25 17:31 dalias Name => Rich Felker
2014-08-25 17:31 dalias Organization => musl libc
2014-08-25 17:31 dalias Section => sem_destroy,
sem_wait, sem_post
2014-08-25 17:31 dalias Page Number => unknown
2014-08-25 17:31 dalias Line Number => unknown
======================================================================