{"id":43029,"date":"2024-04-30T17:07:51","date_gmt":"2024-04-30T21:07:51","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=43029"},"modified":"2024-04-30T17:10:24","modified_gmt":"2024-04-30T21:10:24","slug":"swift-proposal-synchronous-mutual-exclusion-lock","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/04\/30\/swift-proposal-synchronous-mutual-exclusion-lock\/","title":{"rendered":"Swift Proposal: Synchronous Mutual Exclusion Lock"},"content":{"rendered":"

SE-0433<\/a>:<\/p>\n

\n

Not all code may be able (or want) to adopt actors. Reasons for this can be very varied, for example code may have to execute synchronously without any potential for other tasks interleaving with it. Or the async<\/code> effect introduced on methods may prevent legacy code which cannot use Swift Concurrency from interacting with the protected state.<\/p>\n

[…]<\/p>\n

We propose a new type in the Standard Library Synchronization module: Mutex<\/code>. This type will be a wrapper over a platform-specific mutex primitive, along with a user-defined mutable state to protect.<\/p>\n

[…]<\/p>\n

Mutex<\/code> will be decorated with the @_staticExclusiveOnly<\/code> attribute, meaning you will not be able to declare a variable of type Mutex<\/code> as var<\/code>. These are the same restrictions imposed on the recently accepted Atomic<\/code> and AtomicLazyReference<\/code> types. […] We do not want to introduce dynamic exclusivity checking when accessing a value of Mutex<\/code> as a class stored property for instance.<\/p>\n

[…]<\/p>\n

Mutex<\/code> is unconditionally Sendable<\/code> regardless of the value it's protecting. We can ensure the safetyness of this value due to the transferring<\/code> marked parameters of both the initializer and the closure inout<\/code> argument.<\/p>\n<\/blockquote>\n\n

On Apple platforms, this is based on os_unfair_lock<\/a>, which is a bit tricky to directly use from Swift<\/a> because you have to manage the memory for the lock yourself to prevent Swift from moving it. macOS 13 brought OSAllocatedUnfairLock<\/a>, which is Apple’s implementation that handles this for you. Mutex<\/code> is better still because it doesn’t need<\/a> to allocate a separate block of memory for the lock.<\/p>\n\n

Gwendal Roué<\/a>:<\/p>\n

My experience with Swift Concurrency might be somewhat particular.<\/p>

[…]<\/p>

And I’m not sure I’ll replace DispatchQueues with any Swift concurrency constructs any time soon, because a demanding user of SQLite won’t accept to be limited to strictly serialized accesses. SQLite supports concurrent database accesses, including parallel reads and writes. Indeed databases support concurrency in a way that is almost never found in any memory-based synchronization primitive: actors, mutexes, read-write locks are all too limited.<\/p>

Final nail in the coffin: a demanding SQLite user expects to be able to perform synchronous database accesses at will (i.e. when needed) – just like the regular C API – without any risk of concurrency bugs. There’s currently no Swift concurrency construct that allows both sync and async accesses.<\/p><\/blockquote>\n\n

Kyle Howells<\/a>:<\/p>\n

I can’t help feeling Swift’s async, Actor, isolation system is a mistake.<\/p>

Rather than making the safe thing the default, even if a bit slow, and making a slightly awkward API for a “fast mode” it makes most code think about async isolation most of the time.<\/p><\/blockquote>\n\n

Previously:<\/p>\n