リリース一貫性

現代の並列コンピューティングシステムでは、望ましくない結果を避けるために、メモリの一貫性を維持する必要がある。逐次一貫性のような厳密な整合性モデルは、直観的に構成されているが、逐次プログラミングで広く適用されている命令レベルの並列処理を無効にしてしまうため、性能の面ではかなり制限される。より良い性能を得るために、いくつかの緩和されたモデルが検討されており、リリース一貫性は積極的な緩和の試みの一つである^[1]。

逐次整合性はハードウェアの実装だけで実現できるが、リリース一貫性は多くの並列プログラムが適切に同期されているという観察に基づいている。プログラミングレベルでは、あるスレッドのメモリアクセスが他のスレッドの後に発生するように明確にスケジュールするために同期を適用する。同期変数がアクセスされるとハードウェアは、あるプロセッサのローカルな書き込みがすべて他のプロセッサに伝わり、他のプロセッサからの書き込みがすべて見られ、集められていることを確認する。リリース一貫性モデルでは、クリティカルセクションへの出入りの動作をアクイジション(取得)とリリース(解放)に分類し、いずれの場合も、これらの動作を行うタイミングを示す明示的なコードをプログラムに記述する。

一般に分散共有メモリが以下のルールに従う場合、リリース一貫性があるとされている。

1. 共有変数へのアクセスを行う前に、そのプロセッサが以前に行ったすべての取得が完了していなければならない。
2. リリースを実行する前に、このプロセスによる以前のすべての読み取りと書き込みが完了していなければならない。
3. アクイジションとリリースのアクセスは、プロセッサの一貫性がなければならない。

上記の条件が満たされ、プログラムが適切に同期されていれば（すなわち、プロセッサがアクワイアとリリースを適切に実装していれば）、どのような実行結果であっても、逐次整合性に従って実行された場合と全く同じになる。共有変数へのアクセスは、アクワイア（取得）とリリース（解放）によってアトミックな操作ブロックに分割され、ブロック間の競合やインターリーブを防ぐことができる。

ロックリリースはリリース同期の一種と考えられる。右図のようなコードでループ処理が行われているとする。2つのスレッドがクリティカルセクションに入り、aの最新の値を読み込んだ後、クリティカルセクションを抜ける予定である。このコードでは、まずスレッド0がロックを取得してクリティカルセクションに入る。正しく実行するためには、P0が書き込んだaの最新値をP1が読み込まなければならない。その際、一度に1つのスレッドしかクリティカルセクションに入ることができない。したがって、P0がロックを解放した後にP1のロック獲得が成功するように、同期自体が保証されている。また、P0がaの新しい値をP1に伝達しなければならないため、S2→S3の順序が保証されなければならない。同じ理由で、S5はS4の後に発生しなければならない^[2]。

ロック解除問題の後にロック解除完了前にメモリ・アクセスを行っても、ロック獲得後にロック問題の前にメモリ・アクセスを行っても、正しさに影響はない。ただし，ロック取得が完了する前にクリティカルセクションのコードを発行すると、相互排除が保証されない可能性があるため発行できない。

ポストウェイト同期はリリース一貫性のもう一つの実装形態となる。右のコードに示されているように、ポスト操作はすべてのメモリアクセス（特に'a'へのストア）が完了した後にのみ行われれば、正しさが保証される。また読み取り操作は、待機操作が完了するまで実行してはいけない。S2はリリース同期、S3はアクイジション同期として動作する。したがって、S2は前の実行が後に発生しないようにする必要があり、S3は後の実行が前に発生しないようにする必要がある。S2は自分より後の実行を防ぐ必要はなく、同様にS3も自分より後の実行を防ぐ必要はない。