Normative: Add Mutex and Condition #30
Conversation
Uses the reusable token-based design from #27
| 1. Return UnlockTokenCreateIfNeeded(_unlockToken_, _mutex_). | ||
| 1. Else, | ||
| 1. Assert: _result_ is ~timed-out~. | ||
| 1. Return *"timed-out"*. |
There was a problem hiding this comment.
I expect we'll eventually make tokens disposable, which makes the common pattern for timeouts look like
using token = mutex.lock(null, timeout);Returning a string here means that will throw, which is... probably the thing you want? It'll be kind of a cryptic error message, but that's better than thinking you have the lock when you don't (using token = null is legal, so returning null here would make that silently succeed).
| </emu-clause> | ||
|
|
||
| <emu-clause id="sec-atomics.mutex.withlock"> | ||
| <h1>Atomics.Mutex.withLock ( _mutex_, _callback_ [ , _thisArg_ ] )</h1> |
There was a problem hiding this comment.
Do we want tryWithLock? Not sure what to return in the already-locked case, though. Maybe have a parameter to use for that value?
There was a problem hiding this comment.
I don't see that often in other PLs/stdlibs. I'm not against it though.
There was a problem hiding this comment.
Swift 6 (new as of 2 days ago) has withLockIfAvailable1, which is this. I also think that's a better name than tryLock / tryWithLock, incidentally.
Really it's just filling out the missing quadrant on the (lock()+unlock() vs callback) x (blocking vs only-if-available) matrix, though, so it's pretty natural if we already have the other three quadrants filled out.
Footnotes
-
You can read through its history in this thread if you want to. ↩
spec/index.html
Outdated
| </emu-clause> | ||
|
|
||
| <emu-clause id="sec-mutexunlocktokenprototype"> | ||
| <h1>The %MutexUnlockTokenPrototype% Object</h1> |
There was a problem hiding this comment.
Should this be exposed/constructible? Could be nice for some patterns when re-using tokens, instead of needing to wait until you actually want to lock.
There was a problem hiding this comment.
I don't mind, but where would you put it?
There was a problem hiding this comment.
My first instinct is, if the tokens can only be used with mutexes, then Atomics.Mutex.UnlockToken, otherwise Atomics.UnlockToken.
| </emu-note> | ||
|
|
||
| <emu-clause id="sec-atomics.mutex.lock"> | ||
| <h1>Atomics.Mutex.lock ( _mutex_ [ , _unlockToken_ [ , _timeout_ ] ] )</h1> |
There was a problem hiding this comment.
Presumably lockAsync to be added later?
There was a problem hiding this comment.
Yeah, async variants are pretty complex, and TBH I'd prefer to do them as a follow-up proposal entirely.
| </emu-note> | ||
|
|
||
| <emu-clause id="sec-atomics.mutex.lock"> | ||
| <h1>Atomics.Mutex.lock ( _mutex_ [ , _unlockToken_ [ , _timeout_ ] ] )</h1> |
There was a problem hiding this comment.
Also wait why is this static instead of prototype?
There was a problem hiding this comment.
Because shared structs can't point to unshared objects, and functions can't be shared, so having a prototype requires something like per-Realm prototypes that I have talked about in the past, together with solving the "correlation problem" (the registry thing). We're still actively discussing how to solve this issue with Mark & co, and have decided to leave it as an open design question to be settled during Stage 2. As such, the extra complexity of per-Realm prototypes is omitted from the spec draft.
If per-Realm prototypes get consensus, then this will definitely be a prototype.
There was a problem hiding this comment.
(It's my interpretation that where these methods live isn't as major a semantics point as what they do.)
|
The token use for |
Absolutely. The current version only works for blocking waits. |
syg
changed the title
Uses the reusable token-based design from #27
cc @bakkot