ささだです。

shudo computer.org wrote:
> C で書かれたユーザコードが thread safety を意識していない場合でも
> まずいことが起きないようにする、
> っていうことですよね。
> 
> そこまでやってくれる言語処理系って、あるんでしょうか。
> 
> ささださんがそこまで保証したいと考える理由は、
> C で書かれた既存ライブラリの継承 (だけ?) ですよね。
> 
> 
>>　LOCK(str);
>>  sprintf(buff, "%s\n", RSTRING(str)->ptr);
>>　UNLOCK(str);
>>
>>　としなければならず、煩雑で、修正箇所はとても大きい。
> 
> 
> ささださん (+ 有志?) が既存ライブラリを書き換えるのはしんどい、
> ということですよね。
> mode 3 の世界では、ライブラリ開発者自身が
> thread safety を意識した開発を行う、というのが
> 今現在の世界の常識ですよね。
> 
> なら、例えばこうして↓ mode 3 の世界を目指すという手もあるかと思います。
> 
>   - mode 3 の世界でうまく働くような
>     ネイティブコードインタフェースを新たに定義する。
>     Java の JNI のような。
> 
>   - mode 3 対応 Ruby 処理系であっても
>     旧インタフェースに沿ったネイティブコードは実行できるようにする。
>     その際は、仕方ないので、他スレッドを止めるなり何なりする。

　私の目論見は前者だけを提供して、今の Ruby のインタプリタをスレッドセー
フに全部書き換えなきゃいかんなぁ、と思ってました。後者をサポートするつも
りは全然ありませんでした。

　ただ、首藤さんや [yarv-dev:633] Re: thread support でまつもとさんが
仰っているように、段階的に許していく、逆に言うと「スレッドセーフであるこ
とを宣言する API を新設」することで今回は開発していこうかと思っていま
す。そして、スレッドセーフであることを確認した処理から順次それを利用して
いく、と。もちろん、細粒度ロックの機構も用意しないといけませんが、まぁ難
しいことは考えない（ロックの軽量化云々、ロック除去の最適化云々）ことにし
て、とにかく動くものを作ろうと思います。

> 
> おまけ:
> 
>   どうも "giant lock" っていう語が、この場合、しっくり来ませんでした。
>   Linux だとか FreeBSD で "giant lock" と言われてきたものは、
>   さすがに、preemptive なスレッドスケジューリングを許さない、というほど
>   制限の厳しいものではなく、
>   カーネルに入れる / カーネル内の処理ができるスレッドは 1つだけ、
>   というものでした。
>   この場合の "giant lock" は普段の処理では別に獲得する必要はなくて、
>   ある種の処理 (システムコール) をする際にだけ獲得すればよい、と。
> 
>   今回の話の mode 2 というのは、POSIX Threads を使いながらも、
>   その機能がどうあれ、
>     - (Ruby プログラムの) 並列 (!= 並行) 実行を許さない。
>     - VM はスレッドスケジューリングを cooperative に行う。
>   という現 Ruby 実装 (mode 1) と同様の制約を付ける、ということで
>   …短くシンプルに表現するうまい言葉が見つかりません。

　Python の人がジャイアントインタープリタロック、という言葉を使っていた
気がするので、そのまま使ってるんですが、何か適切な言葉がないと面倒ですね
え。それとも、ジャイアントロックじゃなくてジャイアントインタープリタロッ
クと言っておけば十分なのかしら。この場合はインタプリタが VM を複数持っ
て、VM の中でロックしあうのでジャイアントVMロック、というふうにコード中
は使ってますが。

>>　まとめ、比較をしてみます。m1, m2, m3 をそれぞれ mode 1, 2, 3 とよんで
>>ください。
> 
> 
>>・シングルプロセッサでの性能
>>
>>　m2 > m1 > m3
>>
>>　ネイティブスレッドに任せたほうがスレッドスイッチ、スレッド管理、スレッ
>>ド生成　I/O 管理などの効率はよいことが期待出来ます。
> 
> 
> 使う POSIX Threads 実装がカーネルレベルのスレッドだった場合、
> 一般的には、m1 より m2 の方が重くなるんじゃないでしょうか。

　Ruby のユーザレベルスレッドのスイッチはスタックのコピーを伴いますので
重いかなー、と思ってました。I/O 管理はブロック回避のためにいろいろやって
ますし。


>>・生成するスレッドの数の制限
>>
>>　m1 > m2 = m3
>>
>>　1 ネイティブスレッド = 1 Ruby のスレッドだと、ネイティブスレッドの生成
>>上限（たとえば、cygwin では 700 個強でした）に制限されます。
> 
> 
> 最近、Java 5.0 / Linux 2.6 (on VMware & Win XP) で
> 6,000 くらいのスレッドを作りました。
> (同時に runnable だったスレッドは、多分、数百程度だったとは思います。)

　今 Linux atdot.net 2.4.27-2-686 でやったら 1327 個でした。2.4 系は弱い
なぁ。


>>　エンタープライズ用途（CPU を 8 つとか積んでるマシンで 1 つの Ruby プロ
>>セスをぶん回す、など）では m3 がよさそうですが、そもそも Ruby でそういう
>>リクエストはあるのか。それだったら複数プロセッサで dRuby で通信、などの
>>ほうがよさそうに思える。mod_ruby はどうなんだろう。そもそも、エンタープ
>>ライズ分野では SMP 構成よりはクラスタ構成のほうが主流な気がするが、どう
>>なんだろう。
> 
> 
> 数年後は、普通のデスクトップ PC にも 4とか 8のプロセッサコアが
> 載ってると思います。
> もちろん、単一 Ruby VM は 1コアだけ使えれば充分、
> という判断もありだと思います。

　そうですよねぇ。私は並列を生かす仕事をしないといけないんですよねぇ。

-- 
// SASADA Koichi at atdot dot net
//


--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml