cplusplus / nbballot

Handling of NB comments in response to ballots
14 stars 4 forks source link

US364 32.07.2 p13 Clarify spurious failure for try_acquire #359

Closed wg21bot closed 4 years ago

wg21bot commented 4 years ago

The phrasing of the spurious failure case of semaphore try_acquire can confuse readers, who may parse it as being about blocking guarantees or a statement about QoI, rather than capturing various memory model subtleties as intended. Better would be to word this case similarly to mutex try_lock. The proposed change does so.

Proposed change: Replace with "Effects: Attempts to atomically check if the counter is positive and decrement it by one if so, without blocking. If the counter is not decremented, there is no effect and try_acquire immediately returns. An implementation by fail to decrement the counter even if it is positive. [ Note: This spurious failure is normally uncommon, but allows interesting implementations based on a simple compare and exchange ([atomic]). -- end note] An implementation should ensure that try_acquire() does not consistently return false in the absence of contending semaphore operations.“

jensmaurer commented 4 years ago

Suggested wording from reflector discussion:

Effects: Performs an atomic read-modify-write operation ([intro.races]) which determines whether counter is greater than zero, and, if so decrements counter. The determination that counter is greater than zero may fail spuriously. [Note: This means that the semaphore might not be acquired even if it is available. – end note.] An implementation should ensure that determination does not fail in the absence of contending semaphore acquisitions.

BillyONeal commented 4 years ago

After discussion with SG1 folks on Monday, here's a P/R that closely follows the NB comment but also fixes my 'what the atomic op is is not clear' concern. Note that only the first sentence is changed from the NB comment P/R:

Proposed change: Replace with "Effects: Attempts to atomically decrement the counter if it is positive, without blocking. If the counter is not decremented, there is no effect and try_acquire immediately returns. An implementation by fail to decrement the counter even if it is positive. [ Note: This spurious failure is normally uncommon, but allows interesting implementations based on a simple compare and exchange ([atomic]). -- end note] An implementation should ensure that try_acquire() does not consistently return false in the absence of contending semaphore operations.“

jwakely commented 4 years ago

N.B. "An implementation by may fail to decrement the counter even if it is positive."

mclow commented 4 years ago

Resolved by the adoption of P1960

jensmaurer commented 4 years ago

Accepted with modification. See paper P1960R0.