 Relationships |
|
| Anonymous | Login | 2024-10-09 04:42 UTC |
| Main | My View | View Issues | Change Log | Docs |
| 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 | 2024-06-11 08:55 | ||
| Reporter | torvald | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Closed | ||||||
| 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 |
| 2024-06-11 08:55 | agadmin | Status | Applied => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
