Synchronous Mutual Exclusion Lock

SE-0410 で追加された Synchronization モジュールに、新しい同期プリミティブ Mutex<Value> を追加します。Atomic と同様に、使うにはモジュールを明示的に import します。

import Synchronization

final class FancyManagerOfSorts {
    let cache = Mutex<[String: Resource]>([:])

    func save(_ resource: Resource, as key: String) {
        cache.withLock {
            $0[key] = resource
        }
    }
}

Mutex は保護したい値を内部に持ち、withLock のクロージャ内でのみその値に inout でアクセスできます。クロージャの先頭でロックが取得され、抜けるときに解放されます。

型と基本API

Mutex は ~Copyable な struct で、保護対象の型 State 自体も ~Copyable で構いません。

public struct Mutex<State: ~Copyable>: ~Copyable {
    public init(_ state: sending consuming State)
}

extension Mutex: Sendable where State: ~Copyable {}

extension Mutex where State: ~Copyable {
    public borrowing func withLock<Result: ~Copyable, E: Error>(
        _ body: (sending inout State) throws(E) -> sending Result
    ) throws(E) -> sending Result

    public borrowing func withLockIfAvailable<Result: ~Copyable, E: Error>(
        _ body: (sending inout State) throws(E) -> sending Result?
    ) throws(E) -> sending Result?
}

withLockIfAvailable はロックを即時取得できたときだけクロージャを実行し、取得できなかった場合は nil を返します（tryLock 相当）。

基盤となるロック実装はプラットフォームごとに異なり、fairnessは保証されません。保証されるのは「同時に一つの実行コンテキストだけが critical section に入る」ことだけです。

• Darwin系: os_unfair_lock
• Linux: futex
• Windows: SRWLOCK

Sendable と non-Sendable な保護対象

Mutex は State が何であっても無条件に Sendable です。これを安全に成立させているのが、初期化子とクロージャの sending 注釈（SE-0430）です。

• init(_:) の引数が sending consuming なので、初期化に使った non-Sendable な値は以降呼び出し元で参照できません。
• withLock のクロージャ引数 inout State も sending なので、クロージャ内で inout されている値をクロージャ外へ逃がすことはできません。

この仕組みによって、Mutex それ自体をひとつの isolation domain とみなせます。non-Sendable な参照や内部のポインタをロックの外へこっそり送り出す経路が静的に塞がれます。

class NonSendableReference {
    var prop: UnsafeMutablePointer<Int>
}

let nonSendableRef: NonSendableReference = ...
let lockedPointer = Mutex<UnsafeMutablePointer<Int>>(...)

func something() {
    lockedPointer.withLock {
        // error: sending 'inout' parameter transferred out
        //        but hasn't had a value transferred back in.
        nonSendableRef.prop = $0
    }
}

どうしても中身を外へ渡したい場合は、クロージャから抜ける前に新しい値を戻す（$0 を再代入する）ことで、Mutexの domain に新しい値を「送り返した」ことを示します。

func something() {
    lockedPointer.withLock {
        nonSendableRef.prop = $0
        $0 = ...     // 新しい値を domain に送り込む
    }
}

var / inout / mutating の禁止

Mutex は Atomic と同じく @_staticExclusiveOnly が付き、var での宣言や inout 渡しはコンパイルエラーになります。これはロックの安定したアドレスを保ったまま、Swiftの動的排他性チェックと干渉しないようにするためです。let で保持し、borrowing または consuming で渡します。

非再帰であること

Mutex は非再帰です。withLock の中で同じ Mutex に対して再び withLock / withLockIfAvailable を呼ぶと、プラットフォーム依存の挙動になり（デッドロック、プロセスパニック、未規定のいずれか）、少なくともロックが再取得されることはありません。

また、async な文脈でも withLock 自体は使えますが、クロージャ内に await は書けません。中断ポイントを挟んだ先でロックが別スレッドから解放される事態を避けるため、クロージャは同期的に実行しきる必要があります。長時間の非同期処理を守りたい場合はアクターなど別の仕組みを検討します。

アクターとの使い分け

mutexとアクターは、いずれも共有ミュータブル状態を守る仕組みですが性質が大きく異なります。

• mutex: 同期的なロック。取得待ちのスレッドは前進できず、デッドロックやスレッド競合の可能性もある一方、async を持ち込めない同期コードからも使える。
• アクター: 非同期。待機中のタスクは別の仕事を進められ、通常の使い方ではデッドロックしない。一方、中断ポイントでの再入（reentrancy）に伴う状態変化には注意が必要。

デフォルトではアクターで十分なことが多く、Mutex は「アクターが使えない／合わない」場面の補完として位置づけられます。

今後の見通し

以下のような拡張が将来の方向性として挙げられています（speculativeで、実現を約束するものではありません）。

• ガードベースAPI: C++の std::lock_guard やRustの MutexGuard のように、取得トークンのスコープでロックの寿命を表現するAPI。~Copyable かつ ~Escapable な戻り値で安全に表現する案が考えられていますが、nonescapable型の整備を待つ必要があります。
• reader-writerロックや再帰ロック: 読み取りと書き込みで排他性の粒度を変えるロックや、同じスレッドが複数回取得できる再帰ロックといった、別種の同期プリミティブを Synchronization モジュールに追加する方向。