I've found that as the language improves with regards to memory safety, I've still sometimes found myself reaching for a lock, due to the need to have shared mutable state that is accessible from synchronous contexts that may be used on multiple threads. This is especially relevant when working with legacy code in a large codebase that we're attempting to modernize. I've also encountered this with cross-platform code, where NSLock (which lives in Foundation) may not be the best option, but os_unfair_lock is also not possible to use across the board. I've noticed as well that in Apple's public Swift repos, locks are still frequently used behind the scenes, and it seems there's a fairly elegant cross-platform solution already available, but it's not available to consumers of the API; the internal CriticalManagedState (or a similar idea) must be copied into the local library.
I know that using actors is generally the more recommended way of dealing with shared mutable state, but it's not always practical to do so. I also know that discussing future plans can get into awkward territory around here. That said, I'd love to hear if there are plans to introduce native locks into the Swift standard library, as I think it can fill a vital role especially in cross-platform code. I'd also love to hear others' thoughts on this topic.
Is OSAllocatedUnfairLock also available on Swift for Linux and Windows ?
Where I can find a Swift APIs reference document that shows on what platforms a function is available, not only Apple specific platforms ?
To my knowledge, OSAllocatedUnfairLock is only available on Apple platforms, and is not available in any public repos. It's indeed worth bringing up, as it's a great API, but it's a non-starter for cross-platform work.
In my experience, if something isn't in the standard library and is in the documentation materials that come with Xcode, it's pretty safe to assume it's not available on non-Apple platforms.
NIOLock itself should be entirely dependency free, and is licensed under Apache 2.0, so users are free to copy it out and use it directly. Note also NIOLockedValueBox, which is broadly similar in API to OSAllocatedUnfairLock.
surely there is no need for yet another micropackage, a dependency-less module in the existing repo with the lock implementation would be sufficient, no?
i have grown increasingly annoyed with the amount of version timelines that need to be reconciled to use the various server side libraries. (testable builds matter!) we need to stop hitting the "create new GitHub repository" button every time we build something new.
Yeah, I agree with you, having a micropackage isn't good. I just think having a whole ecosystem depend on NIO just to get a cross-platform lock isn't great either. Foundation also has a lock, but right now the options are those two big projects. I kinda feel like another project might be a better fit.
Alternatively, someone could propose this for the standard library. The implementation is sitting right there.
having a whole ecosystem depend on NIOCore is bad, but there is nothing wrong with the whole ecosystem depending on the repository NIOCore lives in. (assuming cloning the repo history doesn't become a bottleneck)
I'm pretty sure that the general mood towards building an "official" lock type is generally positive, and it's only a matter of time. It'd abstract away the underlying differences between platforms as all those floating around implementations do.
To be honest lack of such lock is already felt even by the stdlib with more features having to deal with concurrency and a lock just being the right tool for the job sometimes -- like the recent Observation work had to roll its own lock again which was unfortunate.