Swiftのミューテックスとキャプチャロックアウト

Matt Gallagerの記事の翻訳。



この記事では、Swiftのスレッド化ツールとスレッド同期ツールの欠如について説明します。 Swiftに同時実行性を導入するための提案と、この機能が使用可能になる前に、Swiftでのストリーミング実行で従来のミューテックスと共有可変状態を使用する方法について説明します。



Swiftでミューテックスを使用することは特に困難ではありませんが、この背景に対して、Swiftのパフォーマンスの微妙なニュアンス-クロージャによるキャプチャ中の動的メモリ割り当てを強調したいと思います。 ミューテックスを高速にしたいのですが、ミューテックス内で実行するクロージャを渡すと、メモリのオーバーヘッドが増えるため、パフォーマンスが10倍低下する可能性があります。 この問題を解決するいくつかの方法を見てみましょう。

Swiftのスレッド化の欠如

Swiftが2014年6月に初めて発表されたとき、2つの明らかな欠落がありました。

• エラー処理
• ストリームの実行とスレッドの同期。

エラー処理はSwift 2で実装され、このリリースの重要な機能の1つでした。



ストリーミングの実行は、Swiftによってまだほとんど無視されています。 ストリーム実行用の言語ツールの代わりに、SwiftにはすべてのプラットフォームにDispatch



モジュール（libdispatch、別名Grand Central Dispatch）が含まれており、言語のヘルプを期待する代わりにDispatch



を使用することを暗黙的に提供します。



出荷されるライブラリへの責任の委任は、ストリーム実行プリミティブと厳格なスレッドセーフ（それぞれ）が言語の主な特性になっているGoやRustなどの他の現代言語と比較すると特に奇妙に思えます。 Objective-Cの@synchronized



およびatomic



プロパティでさえ、Swiftにこのようなものがないことと比較すると、寛大なオファーのように見えます。



この言語のこのような明らかな省略の理由は何ですか？

Swiftの将来のマルチスレッド

答えは、Swiftリポジトリでのマルチスレッドの実装の提案で簡単に説明されています 。



私はこの文に言及して、Swift開発者が将来マルチスレッドについて何かをしたいことを強調しますが、Swift開発者Joe Groffが言うことを覚えておいてください：「この文書は単なる提案であり、公式の紹介文ではありません開発。」



この提案は、たとえば、 CycloneまたはRustで、スレッド間でリンクを共有できない状況を説明するように思われました。 結果がこれらの言語に似ているかどうかに関係なく、Swiftは、 Copyable



を実装し、厳密に制御されたチャネル（ Stream



と呼ばれる文で）を介して送信される型を除き、ストリームの共有メモリを削除する予定です。 （ Task



'sと呼ばれる文で）コルーチンも表示されます。これは、非同期ディスパッチブロックとして動作し、一時停止/再開できます。



さらに、この提案では、 Stream / Task / Copyable



プリミティブの上のライブラリに、最も一般的な言語ストリーミング実行Stream / Task / Copyable



を実装できると述べています（Goのchan



、.NETのasync / await



、Erlangのactor



に似てasync / await



ます）。



良さそうに聞こえますが、Swiftでマルチスレッド化を期待する場合は？ Swift 4では？ Swift 5では？ すぐに。



したがって、今ではこれは私たちを助けませんが、むしろ私たちを混乱させます。

現在のライブラリに対する将来の機能の影響

問題は、Swiftが言語での単純なマルチスレッドプリミティブの使用、または将来の手段で置き換えられるか削除されるという理由で、言語関数のスレッドセーフバージョンを使用しないことです。



Swift-Evolutionメーリングリストを読むと、このことの明確な証拠を見つけることができます。

• オブジェクトへの参照（強いものと弱いものの両方）は、「読み取り/書き込み、書き込み/書き込み、または何かが存在する場合/レーシング変数にデータを破壊する」と定義されていません 。 ここでは、この行動を変更したり、統合された「原子」アプローチを提案したりする意図はありません。「私たちが採用する数少ない曖昧な行動ルールの1つ」だからです。 このあいまいな動作の考えられる「修正」は、新しいマルチスレッドモデルです。
• 結果の型（または機能的なインターフェイス以外のその他のスロー手段）は、多数の継続パッシングスタイルアルゴリズムに有用であり、徹底的に議論されますが、最終的には無視されますマルチスレッドの変更の一部として、Swiftが「適切な言語サポートを提供するまで（コルーチンまたは非同期の約束）」。

高速な汎用ミューテックスミューテックスを見つけようとしています

つまり、マルチスレッドの動作が必要な場合、既存のストリーミングツールとミューテックスプロパティを使用して自分でビルドする必要があります。



標準のSwiftミューテックスのヒント ： DispatchQueue



を使用して、その上でsync



を呼び出します。



私はlibdispatchが好きですが、ほとんどの場合、 DispatchQueue.sync



をミューテックスとして使用することは、問題を解決する最も遅い方法であり、 sync



関数に渡されるクロージャーによるキャプチャの避けられないコストのため、他のソリューションよりも1 桁以上遅くなります。 これは、ミューテックスクロージャが周囲の状態をキャプチャする必要があるという事実（特に、保護されたリソースへの参照をキャプチャする）であり、このキャプチャは動的メモリでのクロージャコンテキストの使用を意味します。 Swiftがスタック上の非エスケープクロージャーを最適化する機会を得るまで、クロージャーを動的メモリに配置する余分なコストを回避する唯一の方法は、クロージャーを組み込みにすることです。 残念ながら、これは、Dispatchモジュールの境界など、モジュールの境界内では不可能です。 これにより、 DispatchQueue.sync



、Swiftで不必要に遅いミューテックスになります。



次に最もよくobjc_sync_enter



オプションはobjc_sync_enter



/ objc_sync_exit



です。 libdispatchよりも2〜3倍高速ですが、理想よりもやや遅く（常に再入可能なミューテックスであるため）、Objective-Cランタイムに依存します（したがって、Appleプラットフォームに限定されます）。



ミューテックスの最速オプションはOSSpinLock



はdispatch_sync



よりも20倍以上高速です。 スピンロックの一般的な制限（複数のスレッドが同時に入ろうとするとCPUの負荷が高くなる）に加えて、 iOSには深刻な問題があり、このプラットフォームでの使用にはまったく不適切です。 したがって、Macでのみ使用できます。



iOS 10またはmacOS 10.12、またはそれより新しいものをターゲットにしている場合は、 os_unfair_lock_t



を使用できます。 このパフォーマンスソリューションはOSSpinLock



に近く、最も重大な問題をOSSpinLock



する必要があります。 ただし、このロックはFIFOではありません。 代わりに、ミューテックスは任意の期待（つまり、「unfiar」）に提供されます。 これがプログラムの問題であるかどうかを判断する必要がありますが、一般に、このオプションは汎用ミューテックスの最初の選択肢ではないことを意味します。



これらの問題はすべて、 pthread_mutex_lock



/ pthread_mutex_unlock



唯一のスマートで効率的で移植可能なオプションにします。

ミューテックスと落とし穴キャプチャ回路

純粋なCのほとんどのものと同様に、 pthread_mutex_t



にはかなり不格好なインターフェースがあり、Swiftラッパーを使用するのに役立ちます（特にビルドと自動クリーニングのため）。 さらに、「スコープ付き」ミューテックスを使用すると便利です。ミューテックスは、関数を受け入れてミューテックス内で実行し、関数の両側でバランスのとれた「ロック」と「ロック解除」を提供します。



ラッパーにPThreadMutex



。 以下は、このラッパーでの単純なスコープミューテックス関数の実装です。

 public func sync<R>(execute: () -> R) -> R { pthread_mutex_lock(&m) defer { pthread_mutex_unlock(&m) } return execute() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

速く動作するはずですが、そうではありません。 理由がわかりますか？



この問題は、別のCwlUtils



モジュールで提示されるような再利用可能な関数の実装から発生します。 これにより、 DispatchQueue.sync



の場合とまったく同じ問題が発生します。クロージャーキャプチャの結果、動的メモリが割り当てられます。 このプロセス中のオーバーヘッドにより、関数は必要以上に10倍以上遅く動作します（理想的な0.263秒と比較して、1000万回の呼び出しで3.124秒）。



「キャプチャ」とは何ですか？ 次の例を見てみましょう。

 mutex.sync { doSomething(&protectedMutableState) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミューテックス内で何か便利なことを行うには、 protectedMutableState



への参照を動的メモリのデータである「クロージャコンテキスト」に格納する必要があります。



これは十分無害に見えるかもしれません（結局、キャプチャはクロージャが行うことです）。 ただし、 sync



関数を呼び出すものに埋め込むことができない場合（別のモジュールまたはファイルにあり、モジュール全体の最適化がオフになっているため）、キャプチャ中に動的メモリが割り当てられます。



しかし、これは望ましくありません。 これを回避するには、クロージャをキャプチャする代わりに、クロージャに適切なパラメータを渡します。



警告 ：次のいくつかのコード例はますますおかしくなりつつあり、ほとんどの場合、それらに従わないことをお勧めします。 問題の深さを示すためにこれを行っています。 「その他のアプローチ」の章を読んで、実際に使用しているものを確認してください。

 public func sync_2<T>(_ p: inout T, execute: (inout T) -> Void) { pthread_mutex_lock(&m) defer { pthread_mutex_unlock(&m) } execute(&p) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは良いです...今、関数はフルスピードで動作します（1000万回の呼び出しのテストで0.282秒）。



関数によって渡された値を使用して問題を解決しました。 同様の問題が結果を返すときに発生します。 次の機能：

 public func sync_3<T, R>(_ p: inout T, execute: (inout T) -> R) -> R { pthread_mutex_lock(&m) defer { pthread_mutex_unlock(&m) } return execute(&p) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クロージャが何もキャプチャしない場合でも、元の速度と同じ低速を示します（1.371秒で、速度はさらに低下します）。 結果を処理するために、このクロージャーは動的メモリ割り当てを実行します。



結果にinout



パラメータを導入することでこれを修正できます。

 public func sync_4<T, U>(_ p1: inout T, _ p2: inout U, execute: (inout T, inout U) -> Void) -> Void { pthread_mutex_lock(&m) execute(&p, &p2) pthread_mutex_unlock(&m) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そう呼ぶ

 // ,  `mutableState`  `result`  ,       mutex.sync_4(&mutableState, &result) { $1 = doSomething($0) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フルスピードに戻るか、それに十分に近づいています（1000万回の呼び出しに対して0.307秒）。

別のアプローチ

ロック回路の利点の1つは、見た目が軽いことです。 キャプチャ内の要素は、クロージャの内側と外側で同じ名前を持ち、それらの間の接続は明らかです。 クロージャによるキャプチャを回避し、代わりにすべての値をパラメータとして渡そうとすると、すべての変数の名前を変更するか、シャドウ名を付ける必要があります-理解を容易にすることはできません-そして、誤って変数をキャプチャするリスクがあります再びパフォーマンスが低下します。



すべてを脇に置き、別の方法で問題を解決しましょう。



ファイルにミューテックスをパラメーターとして取る無料のsync



関数を作成できます。

 private func sync<R>(mutex: PThreadMutex, execute: () throws -> R) rethrows -> R { pthread_mutex_lock(&mutex.m) defer { pthread_mutex_unlock(&mutex.m) } return try execute() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数が呼び出されるファイルに関数を配置すると、 ほとんどすべてが機能します。 実行速度が3.043秒から0.374秒に低下する一方で、動的メモリ割り当てのコストを取り除きます。 しかし、直接呼び出しpthread_mutex_lock



/ pthread_mutex_unlock



場合のように、まだ0.263秒のレベルには達していません。 また何が悪いのでしょうか？



同じファイル内にプライベート関数が存在しますが、Swiftはこの関数を完全にインライン化できますが、SwiftはPThreadMutex



パラメーター（コピーするときにpthread_mutex_t



が壊れないように型がclass



ある）の過剰な保持と解放を排除しません。



関数をフリー関数ではなくPThreadMutex



拡張にすることにより、これらの推論とリリースをコンパイラーに回避させることができます。

 extension PThreadMutex { private func sync<R>(execute: () throws -> R) rethrows -> R { pthread_mutex_lock(&m) defer { pthread_mutex_unlock(&m) } return try execute() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、Swiftはself



パラメーターを@guaranteed



として@guaranteed



、保留/解放のコストを排除し、最終的に0.264秒の値を取得します。

ミューテックスではなくセマフォ？

なぜdispatch_semaphore_t



使用dispatch_semaphore_t



ないのですか？ dispatch_semaphore_wait



とdispatch_semaphore_signal



の利点は、クロージャーを必要としないことです-それらは別々の、スコープのない呼び出しです。



dispatch_semaphore_t



を使用dispatch_semaphore_t



て、ミューテックスのような構造を作成できます。

 public struct DispatchSemaphoreWrapper { let s = DispatchSemaphore(value: 1) init() {} func sync<R>(execute: () throws -> R) rethrows -> R { _ = s.wait(timeout: DispatchTime.distantFuture) defer { s.signal() } return try execute() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、 pthread_mutex_lock



/ pthread_mutex_unlock



ミューテックスよりも約3分の1 速い （0.168秒対0.244）ことがわかりました。 ただし、速度は向上しますが、ミューテックスにセマフォを使用することは、一般的なミューテックスに最適なオプションではありません。



セマフォには、多くのエラーや問題が発生します。 これらの中で最も深刻なのは、 優先順位反転フォームです。 優先順位の逆転は、 OSSpinLock



iOSで使用される原因となったのと同じタイプの問題ですが、セマフォの問題はもう少し複雑です。



スピンロックされている場合、優先順位の反転は次を意味します

1. 優先度の高いスレッドはアクティブで回転しており、優先度の低いスレッドが保持しているロックを解除するのを待っています。
2. 優先度の低いスレッドは、優先度の高いスレッドによって使い果たされるため、ロックが解除されることはありません。

セマフォが存在する場合、優先順位の反転は次のことを意味します。

1. 優先度の高いスレッドがセマフォを待機します。
2. 優先順位ストリームはセマフォに依存しません。
3. 低優先度ストリームは、高優先度ストリームが継続できることをセマフォで通知することが期待されます。

中優先度のスレッドは、低優先度のスレッドを使い果たします（これは、スレッドの優先度では正常です）。 しかし、高優先度のフローは低優先度のフローがセマフォで信号を送るのを待つため、高優先度のフローも中優先度のフローによって枯渇します。 理想的には、これは起こらないはずです。



セマフォの代わりに正しいミューテックスが使用された場合、高優先度のストリームの優先度は低優先度のストリームに転送されますが、高優先度の人は低優先度のストリームが保持するミューテックスを期待します-これにより、低優先度のストリームが作業を完了し、高優先度のストリームをロック解除できます ただし、セマフォはストリームによって保持されないため、優先転送は発生しません。



最終的に、セマフォはスレッド間で終了通知を関連付けるのに適した方法です（ミューテックスでは簡単ではありません）が、セマフォの設計は複雑でリスクが伴うため、事前に関係するすべてのスレッドを知っている状況に使用を制限する必要がありますおよびその優先順位—待機中のストリームの優先順位がシグナリングストリームの優先順位以下であることがわかっている場合。



あなたはおそらくあなたのプログラムで異なる優先度を持つスレッドを意図的に作成しないので、これは少し混乱しているように見えるかもしれません。 ただし、Cocoaフレームワークは少し複雑になります。どこでもディスパッチキューを使用し、各キューには「QoSクラス」があります。 また、これにより、キューが異なるスレッド優先度で動作する可能性があります。 プログラム内の各タスク（Cocoaフレームワークを使用してキューに入れられたユーザーインターフェイスやその他のタスクを含む）のシーケンスがわからない場合、突然マルチスレッドの優先順位が発生する可能性があります。 これは避けるのが最善です。

申込み

PThreadMutex



とDispatchSemaphore



実装を含むプロジェクトは、 Githubで入手できます。



CwlMutex.swiftファイルは完全に独立しているため、必要な場合は単純にコピーできます。



または、 ReadMe.mdファイルには、リポジトリ全体のクローン作成と、プロジェクトに作成するフレームワークの追加に関する詳細情報が含まれています。

おわりに

SwiftでMacとiOSの両方に最適で安全なミューテックスオプションはpthread_mutex_tです。 将来的には、Swiftはおそらく、スタック上の非エスケープクロージャーを最適化するか、モジュールの境界を越えてインライン化する機会を得るでしょう。 これらの機能はいずれも、おそらくDispatch.syncの固有の問題を修正し、おそらくそれをより良いオプションにします。 しかし今のところ、それは非効率的です。



セマフォやその他の「軽い」ロックは、いくつかのシナリオでは合理的なアプローチですが、それらは汎用ミューテックスではなく、設計時に追加の考慮事項とリスクを伴います。



どのミューテックスエンジンを選択するかにかかわらず、パフォーマンスを最大化するためにインライン化を提供する際には注意する必要があります。そうしないと、クロージャーによる過剰なキャプチャにより、ミューテックスが10倍遅くなる可能性があります。 Swiftの現在のバージョンでは、コードが使用されているファイルにコードをコピーして貼り付けることを意味する場合があります。



ストリーミングの実行、インライン化、最適化はすべて、Swift 3以外の重要な変更が予想されるトピックです。ただし、現在のSwiftユーザーはSwift 2.3およびSwift 3で作業する必要があります。スコープ付きミューテックスを使用する場合の最大パフォーマンス。

追加：パフォーマンス指標

単純なサイクルが1000万回実行されました。ミューテックスを入力し、カウンターを増やし、ミューテックスを出力しました。 「遅い」バージョンのDispatchSemaphoreおよびPThreadMutexは、テストコードとは別に、動的構造の一部としてコンパイルされました。



結果：

ミューテックスオプション	秒（Swift 2.3）	秒（スイフト3）
PThreadMutex.sync（クロージャによるキャプチャ）	3,043	3,124
DispatchQueue.sync	2,330	3,530
PThreadMutex.sync_3（結果を返す）	1,371	1,364
objc_sync_enter	0.869	0.833
sync（PThreadMutex）（同じファイル内の関数）	0.374	0.387
PThreadMutex.sync_4（ダブル入力パラメータ）	0,307	0.310
PThreadMutex.sync_2（単一のinoutパラメーター）	0.282	0.284
PThreadMutex.sync（インラインの非キャプチャ）	0.264	0.265
直接呼び出しpthread_mutex_lock / unlock	0.263	0.263
OSSpinLockLock	0,092	0.108

使用されるテストコードは関連するCwlUtilsプロジェクトの一部ですが、これらのパフォーマンステストを含むテストファイル（CwlMutexPerformanceTests.swift）はデフォルトではテストモジュールに接続されていないため、意図的に含める必要があります。