goron <naoij@m.ieice.org> writes:

> と、ここで私の言い方が拙かった/途中でごっちゃになったために誤解を招
> くことになった同期ですが、私もコヒーレンシと同期を同一のものと思っ
> ていたわけではありません。ただし、今でも図書などを主とする大方の説
> 明で疑問が残っているひとつとして、コヒーレント機構で解決する同時性
> というのがリアルタイム時間でいいのか、というのはあります。
(略)
> つまり、コヒーレンシと同期は違うものだけど、必ず対で必要な切っても
> 切り離せないものだろうという考えです（そこに対し、そうでもないパタ
> ーンというのが提示されたというのが、今回の最大の収穫かなと思います）。

コヒーレンシというと、何らかの順序関係が入ってきますけど、「リアルタイ
ム」というわけでは必ずしもないですよね。

コヒーレンシというのは大雑把に言って「ある時点で、あるアドレスの内容は
誰が見ても同じ」ということですが、この「ある時点」の定義は、たとえば、
Intelのプロセッサとかだと、
・write操作は、グローバルな(つまり誰が見ても同じ)順序がついている
・1つのwrite操作から次のwrite操作までの間のread操作は、誰が見ても同じ
  値を返す
という定義になっていますよね。

ここでは、write操作とその他のメモリ操作(read/write)の順序さえ逆転しな
ければ良くて、クロックとか実時間とかの概念は入っていないと思います。ま
た、read操作どうしの順序は特に保証されません。(まあ、実際にはwrite操作
がバスクロックで言ってたかだか数サイクルで完了するんでしょうから、実時
間とのずれは、それほどないんでしょうけど。)

> ですので、コヒーレンシのためにキャッシュがいらない、と最初に言った
> のはオーバーで申し訳なかったのですが、常にコヒーレンシを解決してし
> まう（ように見える）スヌープのような機構はtoo muchで、もっと簡単に
> 解決できる機構があるんじゃないかな（特にソフトウエアと協調で）、と
> いうのに今回一番筆を割いていました。

共有メモリを持つ大規模なマルチプロセッサシステムだと、sequential
consistencyみたいなモデルでは制約が強すぎて性能が上がらないので、もっ
とシステムに自由度を与えたモデル(acquire consistencyとかrelease
consistencyとか)が使われますよね。これらでは、個々のread/write 操作の
他に同期のための操作(acquire/release)を使って、順序づけや書き込み通知
の頻度を減らしていますね。

このような一貫性制御をソフトで行なうソフトウエアDSMというシステムがあ
りますが、goronさんの意図しているものと近いのでしょうか?

> 例えばスヌープがなくても、writeしたからといって必ずパージをしてしま
> うのではなく、同期時に最後にアクセスしたプロセス番号（もしくはCPU番
> 号？）を追加しておくだけで、連続アクセスできる/できないを制御できま
> すし。まぁそれもコヒーレンシを意識したプログラムを書くこと自体が、
> そのプログラムの可搬性を狭めることになるので良し悪しということもわ
> かりました。

良く分かりませんが、ディレクトリ式のコヒーレンス制御(「このアドレスの
今のオーナ」をディレクトリという表に記録しておく)に近いのかな?

スヌープのハードウエア(キャッシュラインごとに、2ビット程度の追加)より
軽くなるんでしょうか。

                                前田敦司