A number of enhancements were suggested during the review period: most of these were requests for additional functionality (async locking, throwing an exception on attempted recursive use, etc) that cannot be provided without adding machinery to what is currently a minimal wrapper around platform mutex implementations. The steering group is open to considering adding API for some of these operations in the future, but no additional machinery should be added to the Mutex type in this proposal.
There were also requests for machinery to access the protected state without using the closure-based withLock { } API, such as exposing a value property or load() and store() operations. We feel that these would be quite error-prone, and that there is virtue in having an explicit visible block in source code for readers to see the transaction scope quickly and easily. We might consider adding additional conveniences under a separate proposal, but something like the lock guard suggested in future directions of this proposal seems like a safer alternative if something along these lines is to be added.
Thank you to everyone who participated in the review and pitch process. Your contributions are an important part of making Swift a better language.
One question, I saw a couple of use cases in the stdlib (1) and swift-nio [2] of the current different „lock“ implementations where a lock is held across a withXXX call, eg to safely safely store a continuation in a protected state variable for later use. They currently rely on explicit lock() / unlock() API. Are there spellings of those use cases that would work with the proposed API?
I think the answer is no. This was discussed a lot in the review thread, and the authors (and reviewers, evidently) feel it's better to not support those use-cases in order to keep the API more fool-proof.
There are various existing mutexes / locks, in Apple and third party frameworks, that already (and will continue to) support this; they'll have to be used instead.
Speaking purely for myself, I’d be willing to consider exposing a (very unsafe, attractive nuisance) low-level lock()/unlock() API at some point in time after there’s a body of good examples and patterns using the closure-based API and we get a better understanding of what valid uses genuinely cannot be better expressed with safer patterns, vs just happen to be written that way today.
Hello. I have a question about your philosophy. Like role and responsibility.
In this context, wouldn't DispatchSemaphore, and even Dispatch Framework, be able to go inside of SSL? because I think the DispatchSemaphore is exist for the same purpose.
DispatchSemaphore is a signalling semaphore, not a lock. Although both structures are used for concurrent programming, especially in an environment without async, they are not interchangeable.
As well, the libdispatch library is not available on all platforms that Swift supports and includes a significant amount of infrastructure that would be unnecessary for someone who just needs a mutex.