-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
US364 32.07.2 p13 Clarify spurious failure for try_acquire #359
Comments
Suggested wording from reflector discussion:
|
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: |
N.B. "An implementation |
Resolved by the adoption of P1960 |
Accepted with modification. See paper P1960R0. |
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.“
The text was updated successfully, but these errors were encountered: