Swift 4より前は、言語は重複するメモリアクセスを許可しており、プログラマーの規律に依存して未定義の動作を防いでいました。Appleは排他性の法則を基本的なメモリ安全性保証として導入し、任意の変数が複数の読み取り者または1人の書き込み者によってアクセスされることは許可されているが、同時には許可されないと義務付けました。
主な問題は、二つの可変参照、または一つの可変参照と一つの不変参照が同じメモリ位置に同時にアクセスする場合に発生します。このシナリオは通常、inoutパラメータ、変化をもたらすメソッド、または重複するクロージャキャプチャにおいて現れ、データ競合や不整合のスナップショット、ヒープの破損を引き起こします。
Swiftはハイブリッドによる強制戦略を実装しています。コンパイラは静的な定義-使用分析を実行して、コンパイル時に明白な違反を排除します。例えば、同じ変数を二つのinout引数として関数に渡すことなどです。エスケープクロージャ、長期間の操作、または実行時依存のエイリアスを含む複雑なシナリオにおいて、コンパイラは動的計測を導入します。この実行時トラッキングは、スレッドごとにアクセスセットを維持します。重複する可変アクセスが検出されると、プログラムは未定義の動作を示すのではなく、即座にトラップします。
struct SignalProcessor { var waveform: [Float] mutating func amplify(by factor: Float, using buffer: (inout [Float]) -> Void) { buffer(&waveform) } } var processor = SignalProcessor(waveform: [0.1, 0.2, 0.3]) // 実行時トラップ: 'processor.waveform'への重複アクセス processor.amplify(by: 2.0) { wave in processor.waveform = [1.0] // 'wave'がinout参照を保持している間に書き込みを試みる wave[0] = 0.5 }
iOS向けのリアルタイムオーディオ合成アプリケーションは、高優先度のDispatchQueue上でオーディオバッファをレンダリングし、UIスレッドは波形データを視覚化しました。パラメータの迅速な調整中に間欠的なクラッシュが発生し、クラッシュログはUnsafeMutablePointer操作内のヒープ破損を示していました。
開発チームは三つの異なるアーキテクチャソリューションを検討しました。
os_unfair_lock同期を使用した実装。共有のAudioBuffer構造を軽量スピンロックで保護しました。これによりデータ競合は防げましたが、オーディオコールバック（ブロックすることは決して許されない）とUIスレッドの間のロック競合がオーディオのドロップアウトを引き起こしました。さらに、UIがロックを保持している間にリアルタイムスレッドが待機することで優先度反転が発生し、Core Audioの厳密なタイミング要件に違反しました。
不変値コピーを使用した実装。AudioBufferをstructにリファクタリングし、毎フレームUIスレッドにコピーを渡しました。これにより同期の必要はなくなりましたが、許容できないレイテンシが生じました。60Hzで1024サンプルのバッファをコピーすることで、毎秒メガバイトの一時メモリが割り当てられ、SwiftのARCトラフィックとCore Foundationアロケーターの圧力が発生し、聞こえるグリッチが引き起こされました。
排他制御を厳密なスコープで活用する実装。オーディオコールバックがバッファーへの排他的アクセスを確保することで共有可変状態を排除しました。inoutパラメータを使用して処理段階を分け、UIには読み取り専用スナップショットを非変化的アクセサを介して提供しました。このソリューションは、Swiftのコンパイル時排他チェックを活用し、安全性を証明しつつ、実行時の同期オーバーヘッドを完全に排除し、重複するミューテーションの可能性を防ぎました。
このリファクタリングは、ヒープ破損によるすべてのクラッシュを排除しました。ロックプリミティブとメモリ割り当ての疲弊を取り除き、CPU使用率は40％減少し、オーディオパイプラインは重負荷状態でも問題なく動作しました。
排他制御が同時読取りアクセスを許可する理由は何ですか？重複する読み取り-書き込みでトラップになるのはなぜで、Swiftはどのようにこれを機械語レベルで区別するのですか？
候補者はしばしば排他性を一般的なスレッドセーフ性と混同します。Swiftは状態を変更できないため、複数の同時読み取りのみを許可しますが、書き込みには排他性が必要です。機械語レベルにおいて、コンパイラは読み取り専用アクセスの実行時トラッキングを省略します（スレッドサニタイザーでコンパイルされない限り）、一方、書き込みはswift_beginAccess実行時呼び出しをトリガーし、メモリ位置をスレッドローカルのアクセスセットに登録します。実行時はフラグシステム（読み取りと変更）を使用して競合を判断し、同時読み取りを許可し、変更フラグが既存のアクセスに遭遇した場合にトラップします。
Swiftはasync/awaitコード内のサスペンションポイントをまたぐ排他違反をどう処理しますか？
多くの候補者はasync/awaitが自動的に排他性の懸念を解決すると仮定しています。しかし、Swiftはawaitを潜在的なアクセス境界として扱います。タスクが変数へのinout参照を保持し、awaitに遭遇すると、コンパイラはアクセスがサスペンション前に終了することを証明するか、サスペンションをまたいで拡張する必要があります。実行時はこれらのアクセスをタスクごとにトラッキングします。別のタスクが最初のタスクが排他的権利を保持している間に同じメモリにアクセスしようとすると、実行時はトラップします。開発者はawait境界を越えてinout参照を保持しないようにするか、状態をActors内にカプセル化してサスペンション間で適切な隔離を確保する必要があります。
実行時の排他チェックを無効にする特定のコンパイラ最適化フラグは何ですか？その結果生じる壊滅的な故障モードは？
候補者はしばしば排他性が不変であると考えています。Swiftはパフォーマンスに重要なコード用にすべての実行時排他チェックを無効にする-Ouncheckedコンパイルモードを提供します。この設定では、並行するクロージャからの重複するinout変更など、潜在的な排他違反が決定的なトラップではなく、サイレントなヒープ破損を引き起こします。これは、長さフィールドがバッファ内容に一致しなくなったStringストレージや、範囲外のメモリアクセスを引き起こす壊れたArrayメタデータ、または壊れたポインタが後に間接参照される場合の任意のコード実行として現れる可能性があります。このフラグは、重複アクセスがないことが正式な検証または徹底的な静的分析で証明された場合にのみ使用すべきです。