Re: SMP (Re: Xeon)
----- Original Message -----
From: "Shinji KONO" <kono@ie.u-ryukyu.ac.jp>
Newsgroups: fj.comp.arch
Sent: Saturday, September 06, 2003 6:07 PM
Subject: Re: SMP (Re: Xeon)
-- Snip --
>
> > 共有メモリの共有のセマンティクスは、どうなっているんでしょう
> > か。同期処理と一体化したようなもの(たとえばrelease
> > consistency)は、使われているんでしょうか。
Memory consistency modelは,通常,CPUのアーキテクチャで規定されているの
で,共有メモリをUMAで実装するかCC-NUMAで実装するかで変えるということはないと
思います。弱い方に変えたりすると,昔,動いていたプログラムがミステリアスに動
かなくなったりして,大問題になります。
Sunの例でいうと,Memory consitencyはTotal Store Orderで,ストアは命令順に
実行,ロード同士の順序も命令順で,但し,ロードはストアを追い越して前に出られ
るという規則です。これを止めるにはバリア命令があり,バリアを越えて前後には移
動しないという仕様になっています。
AlphaとかPowerとかItaniumはWeak Consistencyで,原則的には命令に出てくる順
序と実行される順序は無関係です。明に順序を付ける場合はバリア命令を入れる必要
があります。
プロセサ間の同期を取る場合は,SWAPとかのアトミックにロードとストアをやる命
令があり,これでセマフォなどを作って排他制御するのが一般的ですが,TSOのよう
なある順序性が保証されている場合は,Dekker's Algorithmのようなやり方で同期を
とることも可能です。
>
> UMAっていう時には共有のセマンティクスはなくて、みんなで書き
> 込むとどうなるかわからないってものだと思います。
>
> Sequent は、なんかlock機構が入っていたと記憶します。アクセス
> する前に、なんかのマクロを呼ぶみたいな方法ですね。共有メモリ
> に変なセマンティクスをいれてなんとかするってのは、僕はあんま
> り良い方法だとは思わない。同期機構は分割統治を意識して、
> 少数で共有された多数の同期機構を用いるのが良いはずです。
> 分割手法のないロック機構はだめだと思う。
>
> > Java をマルチスレッドで走らせて、ちゃんと走るんでしょうか。
論理的には問題ない筈です。
>
> それは、また、別な問題ですよね。ちゃんとってのがパフォーマンス
> が出るかって問題だとすると言語的にも実装的にも難しいんですよね。
> 共有されているオブジェクトを Reference counting でGCするような
> 実装で、何も考えずにパフォーマンスが出るSMPを作れってのは、
> ちょっと勝手すぎると思う。
何も考えずにパフォーマンスが出るのが理想なのですが,現実はなかなかそうはい
きません。
Ando_san
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735