Loading article…
リリース一貫性は、並行プログラミング(分散共有メモリ、分散トランザクションなど) で使用される同期ベースの一貫性モデルの 1 つです。
導入
現代の並列コンピューティングシステムでは、望ましくない結果を避けるためにメモリの一貫性を維持する必要があります。シーケンシャル一貫性のような厳密な一貫性モデルは直感的に構成されていますが、シーケンシャルプログラミングで広く適用されている命令レベルの並列性を無効にするため、パフォーマンスの面で非常に制限的になる可能性があります。より良いパフォーマンスを実現するために、いくつかの緩和モデルが検討されており、リリース一貫性は積極的な緩和の試みです。[1]
リリース一貫性とシーケンシャル一貫性
ハードウェア構造とプログラムレベルの取り組み
順次一貫性はハードウェア実装によって簡単に実現できますが、リリース一貫性は、ほとんどの並列プログラムが適切に同期されているという観察にも基づいています。プログラミング レベルでは、同期は、1 つのスレッド内の特定のメモリ アクセスが別のスレッドの後に発生するように明確にスケジュールするために適用されます。同期された変数にアクセスすると、ハードウェアによって、プロセッサのローカルなすべての書き込みが他のすべてのプロセッサに伝播され、他のプロセッサからのすべての書き込みが認識され、収集されます。リリース一貫性モデルでは、クリティカル セクションに入るアクションと出るアクションは取得と解放に分類され、どちらの場合も、これらの操作をいつ実行するかを示す明示的なコードをプログラムに配置する必要があります。
連続的に一貫した結果を得るための条件
一般的に、分散共有メモリは、以下の規則に従う場合、リリース一貫性がある：[2]
1. 共有変数へのアクセスを実行する前に、このプロセッサによる以前の取得がすべて完了している必要があります。
2. リリースを実行する前に、このプロセスによる以前の読み取りと書き込みがすべて完了している必要があります。
3. 取得アクセスと解放アクセスはプロセッサ一貫性を保つ必要があります。
上記の条件が満たされ、プログラムが適切に同期されている場合 (つまり、プロセッサが acquire と release を適切に実装している場合)、実行結果は、順次一貫性に従って実行された場合とまったく同じになります。実際には、共有変数へのアクセスはacquireプリミティブとreleaseプリミティブによってアトミック操作ブロックに分割されるため、ブロック間の競合やインターリーブが防止されます。
実装
ロックの解放は、解放同期の一種と見なすことができます。右に示すコードを使用してループ操作が実行されると仮定します。2 つのスレッドがクリティカル セクションに入り、aの最新の値を読み取り、クリティカル セクションを終了しようとします。コードでは、スレッド 0 が最初にロックを取得してクリティカル セクションに入ることを示しています。正しく実行するには、P1 はP0 によって書き込まれたaの最新の値を読み取る必要があります。その場合、クリティカル セクションに同時に存在できるスレッドは 1 つだけです。したがって、同期自体によって、P0 によるロック解放後に P1 でのロック取得が成功することが保証されます。さらに、P0 はaの新しい値をP1 に伝播する必要があるため、S2 -> S3 の順序が保証される必要があります。同じ理由で、S5 は S4 の後に発生する必要があります。[3]
ロック解除が完了する前にロック解除発行後のメモリアクセスを行ったり、ロック取得後にロック発行前のメモリアクセスを行ったりしても、正確性には影響ありません。ただし、相互排他性が保証されない可能性があるため、クリティカル セクション内のコードはロック取得が完了する前に発行することはできません。
待機後
ポスト待機同期は、リリース一貫性の別の実装形式です。右のコードに示すように、ポスト操作がすべてのメモリ アクセス、特に 'a' へのストアが完了した後にのみ行われる場合、正確性を確保できます。それとは別に、読み取り操作は待機操作が完了するまで実行しないでください。S2 はリリース同期として機能し、S3 は取得同期として機能します。したがって、S2 はその後に実行される前の実行を防ぐ必要があり、S3 はそれより前に実行される後の実行を防ぐ必要があります。S2 はそれより前に実行される後の実行を防ぐ必要はありません。同様に、S3 はそれより後に実行される前の実行を防ぐ必要はありません。
遅延リリースの一貫性
遅延リリース一貫性はリリース一貫性をさらに最適化したものです。これは、取得アクセスを実行するスレッドは、取得アクセスが完了するまで他のスレッドによって書き込まれた値を必要としないことを前提としています。したがって、一貫性のすべての動作を遅延させることができ、書き込み伝播のタイミングを調整することができます。[4]
例
右の図で説明されているシナリオを検討してください。このケースは、リリース一貫性モデルに基づくキャッシュ コヒーレント システムで書き込み伝播が実行される場合を示しています。変数datum は、datumIsReadyが伝播される前に完全に伝播されます。ただし、 datumの値はP1 の同期アクセスの取得後まで必要ないため、プログラムの結果に悪影響を与えることなく datumIsReadyとともに伝播できます。
2 番目の画像は、遅延リリース一貫性が適用された場合を示しています。このシナリオでは、リリース同期の前に書き込まれたすべての値が遅延され、リリース アクセス自体の伝播とともに伝播されます。したがって、datumとdatumIsReady はリリース ポイントで一緒に伝播されます。
「TreadMarks」[5]は遅延リリース一貫性の実際の応用である。
リリースの一貫性よりもパフォーマンスの向上
遅延リリース一貫性は、特定のケースではリリース一貫性よりもパフォーマンスが優れている場合があります。プロセッサ間の帯域幅が小さいシステムの場合、または小さなデータ ブロックの頻繁な伝播と大きなデータ ブロックの伝播の頻度の低さが原因でオーバーヘッドが高くなるという問題がある場合、LRC はパフォーマンスを大幅に向上させることができます。
実際のハードウェア実装ではなく、ソフトウェア レベルの共有メモリ抽象化を採用しているシステムについて考えてみましょう。このシステムでは、書き込み伝播はページ単位で実行されるため、このページ内の 1 つのブロックのみが変更される場合、ページ全体を伝播するには非常にコストがかかります。したがって、書き込み伝播はリリース同期ポイントに達するまで遅延され、この時点でページ全体が変更され、ページ全体が伝播されます。
欠点
LRC では、同期の解放ポイントで書き込みの伝播を一括して実行する必要があります。このような大量の書き込みを一括して伝播すると、解放アクセスとそれに続く取得アクセスが遅くなります。そのため、ハードウェア キャッシュ コヒーレンス システムのパフォーマンスを向上させることはほとんどできません。
リリース一貫性とその他の緩和一貫性モデル
弱い順序付け（一貫性が弱い）
リリース一貫性は、弱い順序付けに比べてプログラマーに多くのことを要求します。プログラマーは、同期アクセスを同期アクセスとしてだけでなく、取得または解放としてラベル付けする必要があります。弱い順序付けと同様に、リリース一貫性では、コンパイラーがロードとストアを自由に並べ替えることができますが、取得同期を超えて上方に移動することはできず、リリース同期を超えて下方に移動することはできません。ただし、リリース一貫性の柔軟性とパフォーマンスの利点は、同期アクセスが適切に識別され、取得と解放として識別される必要があるという犠牲を払って得られます。弱い順序付けとは異なり、同期アクセスは命令オペコードだけでは簡単に識別できません。したがって、取得と解放の同期アクセスを適切に識別する負担はプログラマーの肩にかかっています。[3] [6]
プロセッサの一貫性については、すべてのプロセスは、各プロセッサからの書き込みを、開始された順序で参照します。異なるプロセッサからの書き込みは同じ順序で参照されない場合がありますが、同じ場所への書き込みはどこでも同じ順序で参照されます。プロセッサの一貫性と比較すると、リリースの一貫性は、プロセッサの一貫性で発生するストア間の順序付けを強制しないため、より緩やかです。コンパイラの最適化に対する制限が比較的少ないため、プログラマの直感に従いません。
参照
参考文献
- ^ スケーラブルな共有メモリ型マルチプロセッサにおけるメモリの一貫性とイベント順序付け (Kourosh Gharachorloo、Daniel Lenoski、James Laudon、Phillip Gibbons、Anoop Gupta、John Hennessy 著) は、ISCA '90 Proceedings of the 17th annual international symposium on Computer Architecture に掲載されました。
- ^ Tanenbaum, Andrew (1995).分散オペレーティングシステム. Pearson Education. pp. 327–330. ISBN 9788177581799。
- ^ ab Solihin, Yan (2015).並列マルチコアアーキテクチャの基礎. Chapman & Hall/CRC 計算科学. pp. 315–320. ISBN 9781482211184。
- ^ Pete Keleher、Alan L. Cox、Willy Zwaenepoel によるソフトウェア分散共有メモリの遅延リリース一貫性は、Proceeding ISCA '92 Proceedings of the 19th annual international symposium on Computer Architecture に掲載されています。
- ^ TreadMarks: 標準ワークステーションおよびオペレーティング システム上の分散共有メモリ (Pete Keleher、Alan L. Cox、Sandhya Dwarkadas、Willy Zwaenepoel 著) は、USENIX Winter 1994 Technical Conference の WTEC'94 Proceedings of the USENIX Winter 1994 Technical Conference に掲載されています。
- ^ Culler, David; Gupta, Anoop; Singh, Jaswinder (1997).並列コンピュータアーキテクチャ: ハードウェア/ソフトウェアアプローチ. Morgan Kaufmann Publishers Inc. pp. 620–626. ISBN 1558603433。