0000869: Concept of being "blocked" on a semaphore is not defined but needed for sem_destroy rules

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

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
(0002398) 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[^]