首藤です。

> 　ささだです。

> 　いくつかの実装方法があると思うので、その辺をまとめてみたいと思います。

> mode 3) スレッドライブラリ利用＋細粒度ロック

> 　オブジェクトに対する操作で、いろいろと排他制御を付ける必要がある。
>
> 　たとえば、String オブジェクトの RSTRING(str)->ptr のような操作は排他制
> 御が必要になる（これを全部排除しようとすると大変...）。これは、例えば
> ptr を取得したあと、スレッドスイッチが起こり、他のスレッドが str に対し
> て破壊的操作をして、ptr が指しているメモリオブジェクトを REALLOC なりし
> た場合、元のスレッドが free したメモリオブジェクトを参照してしまいます。

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 処理系であっても
    旧インタフェースに沿ったネイティブコードは実行できるようにする。
    その際は、仕方ないので、他スレッドを止めるなり何なりする。


おまけ:

  どうも "giant lock" っていう語が、この場合、しっくり来ませんでした。
  Linux だとか FreeBSD で "giant lock" と言われてきたものは、
  さすがに、preemptive なスレッドスケジューリングを許さない、というほど
  制限の厳しいものではなく、
  カーネルに入れる / カーネル内の処理ができるスレッドは 1つだけ、
  というものでした。
  この場合の "giant lock" は普段の処理では別に獲得する必要はなくて、
  ある種の処理 (システムコール) をする際にだけ獲得すればよい、と。

  今回の話の mode 2 というのは、POSIX Threads を使いながらも、
  その機能がどうあれ、
    - (Ruby プログラムの) 並列 (!= 並行) 実行を許さない。
    - VM はスレッドスケジューリングを cooperative に行う。
  という現 Ruby 実装 (mode 1) と同様の制約を付ける、ということで
  …短くシンプルに表現するうまい言葉が見つかりません。


> 　まとめ、比較をしてみます。m1, m2, m3 をそれぞれ mode 1, 2, 3 とよんで
> ください。

> ・シングルプロセッサでの性能
>
> 　m2 > m1 > m3
>
> 　ネイティブスレッドに任せたほうがスレッドスイッチ、スレッド管理、スレッ
> ド生成　I/O 管理などの効率はよいことが期待出来ます。

使う POSIX Threads 実装がカーネルレベルのスレッドだった場合、
一般的には、m1 より m2 の方が重くなるんじゃないでしょうか。

> ・生成するスレッドの数の制限
>
> 　m1 > m2 = m3
>
> 　1 ネイティブスレッド = 1 Ruby のスレッドだと、ネイティブスレッドの生成
> 上限（たとえば、cygwin では 700 個強でした）に制限されます。

最近、Java 5.0 / Linux 2.6 (on VMware & Win XP) で
6,000 くらいのスレッドを作りました。
(同時に runnable だったスレッドは、多分、数百程度だったとは思います。)


> 　エンタープライズ用途（CPU を 8 つとか積んでるマシンで 1 つの Ruby プロ
> セスをぶん回す、など）では m3 がよさそうですが、そもそも Ruby でそういう
> リクエストはあるのか。それだったら複数プロセッサで dRuby で通信、などの
> ほうがよさそうに思える。mod_ruby はどうなんだろう。そもそも、エンタープ
> ライズ分野では SMP 構成よりはクラスタ構成のほうが主流な気がするが、どう
> なんだろう。

数年後は、普通のデスクトップ PC にも 4とか 8のプロセッサコアが
載ってると思います。
もちろん、単一 Ruby VM は 1コアだけ使えれば充分、
という判断もありだと思います。


Kazuyuki Shudo/首藤一幸   私をたばねないで あらせいとうの花のように
  shudo computer.org   http://www.shudo.net/

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