私のアプリケーションはGCDを大量に使用しており、ほとんどすべてがディスパッチによって処理される小さなタスクに分割されています。しかし、基礎となるデータモデルは大部分が読み込まれ、ときどきしか書き込まれません。GCDによる読み書きロック
私は現在、読み取り中に重要なデータ構造への変更を防ぐためにロックを使用しています。しかし、今日ロックを調べた後、NSConditionLockと読み書きロックに関するページが見つかりました。後者はまさに私が必要なものです。
私はこの実装が見つかりました：http://cocoaheads.byu.edu/wiki/locks。私の質問は、この実装はGCDで動作し、PThreadsを使用しているのですか？
それでも機能します。 pthreadsはMac OS X上の他のすべてのスレッド使用APIの基礎となるスレッドAPIです（マッハのスレッドアクティベーションがありますが、それはAPIではなくSPIです）。しかし、pthreadsロックでは実際にpthreadを使用する必要はありませんスレッド。
の場合、GCDはiOS 5の場合より良い代替方法を提供します：dispatch_barrier_async()基本的には、プライベート同時キューがあります。通常の方法ですべての読み取り操作を提出します。バリアルーチンを使用して書き込み操作をサブミットします。タダ！読み書きロック。
WWDC 2011 session video for Session 210 - Mastering Grand Central Dispatchへのアクセス権がある場合、これについて詳しく知ることができます。
また、すべての読み取り/書き込み操作のシリアルキューを維持することを検討することもできます。 dispatch_sync()そのキューに書き込むことで、データモデルへの変更がすぐに適用され、dispatch_async()すべての読み込みがアプリでうまくいっていることを確認できます。
すべての読み取りと書き込みが行われる単一のシリアルキューがあるので、書き込み中に読み取りが行われないようにしてください。これはロックよりもはるかにコストがかかりませんが、複数の '読み取り'操作を同時に実行することはできません。これは、ほとんどのアプリケーションで問題を引き起こす可能性は低いです。
dispatch_barrier_async()を使用すると、バリアブロックが実行される前に、キュー内の既存のすべてのタスクを完了する必要があるため、実際にコミットするのに任意の時間がかかることがあります。
うーん、シリアルキューで非同期ディスパッチが可能だったことさえ気づいていませんでした。これは面白いアイデアのように聞こえる...すべての読み込みはかなり小さい編集ですが、書き込みは通常、読み込み、編集、そしてデータの再保存を意味します。 –
通常、あなたはここで示唆されているものの反対をします。読者は通常、発信者に戻る前に結果を得る必要があるので、同期して提出する必要があります。呼び出し側は、外部から観測可能な状態が書き込まれた日付と一致することのみを気にするので、書き込みは非同期で行うことができます。これは、キューがシリアルであるために書き込みが完了するまで読み取りを続行できないためです。指摘されているように、複数のリーダーでは役に立ちません。 –
ああ、私は障壁について読んでいましたが、現時点では実用的なアプリケーションを考えることができませんでした（私はほとんどその間にマルチスレッドを使用していました）。ありがとう、私はそれを使用できるかどうかを試してみよう！ –
Mike Ashはまた、GCDを使用してリーダーライターの同期を達成する方法の良い例を提供しています。 http://www.mikeash.com/pyblog/friday-qa-2011-10-14-whats-new-in-gcd.html –