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
0001076 [1003.1(2013)/Issue7+TC1] Base Definitions and Headers Comment Enhancement Request 2016-09-09 16:12 2020-04-21 13:54
Reporter torvald View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Torvald Riegel
Organization Red Hat
User Reference
Section Cancellation Points
Page Number 517
Line Number 18121
Interp Status ---
Final Accepted Text Note: 0003938
Summary 0001076: Cancellation Points
Description sem_wait is currently part of the "shall occur" list. This is suboptimal:

(1) It adds overhead to the fast paths of any semaphore implementation (ie, checking for cancellation, which will likely at least require touching an additional cache line).

(2) It creates an inconsistency with sem_trywait semantics in that sem_trywait isn't really a "subset" of sem_wait anymore. Something like "if (sem_trywait(...) != 0) sem_wait(...);" kills cancellation. To be consistent wrt cancellation, sem_trywait would have to be a cancellation point too.

(3) Because the implementation is allowed to decide between cancellation and success when a cancellation request races with unblocking *during* the execution of sem_wait, the POSIX requirement that sem_wait should be a cancellation point regardless of whether it blocks is only exploitable by programs that enforce that the cancellation request is issued before sem_wait is called. This requires active synchronization, and thus the program would already have been able to check whether it should continue to compute or stop. Thus, using this reliably doesn't add functionality that the program wouldn't be able to implement otherwise.
Desired Action I think that the description of when cancellation requests have to be acted upon could be improved. Without reading the rationale ("Thread Cancellation Overview", esp. first paragraph of "Cancellation Points" bullet), it's hard to see that the "may" vs. "shall" lists also allow for different treatment of the sem_wait issue I described (eg, pthread_rwlock_rdlock implementations don't need to check).

It seems the cleanest specification of cancellation would be to say that a function that is considered to have a cancellation point will eventually act upon a cancellation request, provided that it is blocked.

This adds the forward progress requirement for acting upon a cancellation request (ie, the "eventually"), and avoids the weasel-wording in the last sentences of the section (ie, timeouts and when event and cancellation request happen without enforced ordering). It also avoids having to check for cancellation in functions that don't block (which will always affect fast-paths), yet prevents a thread from being blocked indefinitely. It would not make "shall occur" functions points that can be interrupted regardless of whether the thread actually makes progress or not.

Whether a particular function is in the "shall" or "may" camp seems pretty arbitrary (at least, arguably, different programs would benefit from different functions being in "shall" vs. "may"). Therefore, cancellation seems more useful as a mechanism for preventing indefinite blocking (ie, only cancel if blocked) instead of having even deferred cancellation be something like unconditional interruption at functions arbitrarily considered safe points (ie, functions in which cancellation points "shall occur").
Tags issue8
Attached Files

- Relationships

-  Notes
(0003938)
geoffclare (manager)
2018-03-22 15:27

Move sem_wait() and sem_timedwait() from the "shall" list to the "may" list.
(0003939)
shware_systems (reporter)
2018-03-22 15:30

It was discussed whether or not other IPC group interfaces might also be candidates for moving to "may fail" list, but no existing compelling reason for making this change was known.
(0003940)
eblake (manager)
2018-03-22 15:31

The 2018-03-22 meeting also mentioned that mq_receive( ), mq_send( ), mq_timedreceive( ), mq_timedsend( ) might be candidates for similar treatment, but that we were uncomfortable combining that action onto this particular bug report. A separate bug should be opened if similar research and rationale can be made for moving those functions from the "shall" list to the "may" list.

- Issue History
Date Modified Username Field Change
2016-09-09 16:12 torvald New Issue
2016-09-09 16:12 torvald Name => Torvald Riegel
2016-09-09 16:12 torvald Organization => Red Hat
2016-09-09 16:12 torvald Section => Cancellation Points
2016-09-09 16:12 torvald Page Number => 1
2016-09-09 16:12 torvald Line Number => 1
2018-03-08 16:34 nick Page Number 1 => 517
2018-03-08 16:34 nick Line Number 1 => 18121
2018-03-08 16:34 nick Interp Status => ---
2018-03-22 15:27 geoffclare Note Added: 0003938
2018-03-22 15:28 geoffclare Final Accepted Text => Note: 0003938
2018-03-22 15:28 geoffclare Status New => Resolved
2018-03-22 15:28 geoffclare Resolution Open => Accepted As Marked
2018-03-22 15:28 geoffclare Tag Attached: issue8
2018-03-22 15:30 shware_systems Note Added: 0003939
2018-03-22 15:31 eblake Note Added: 0003940
2020-04-21 13:54 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker