2011/09/09
言語レベルのスレッド
(続)Haskell(GHC)での軽量ユーザスレッドの実装方法 - あどけない話
ユーザスレッドの実装は、外部言語の関数呼び出しをサポートする際に行き詰まることが多い。つまり、呼び出した外部言語の関数でブロックされ、他のユーザスレッドが動かなくなる。
Haskell では、外部言語の関数呼び出し専用のカーネルスレッドを用意していて、ユーザスレッドがブロックされないようになっている。この手法は素晴らしいが、他の言語コミュニティは、素晴らしさに気付いていないようだ。
Scheme界では、確かBiglooが似たようなことをやってたと思う。Schemeレベルの スレッドはユーザレベルの軽量スレッドで、ブロックする可能性のある操作を カーネルスレッドに依頼するという。もうずいぶん前に聞いた話だから 定かではないけれど。確かFairThreadsモデルの上に構築されてたって 話だった。
この論文はCだし、Javaの実装もあるからScheme界限定ってわけじゃないのか。
Gaucheでスレッドをどう見せるべきかってところは結構悩んだんだけれど、 言語レベルスレッドのサポートが欲しい2大理由が
- ブロッキングI/Oを気にせず書きたい
- マルチコアを使い切りたい
だったのと、ユーザレベルスレッドはSchemeなら欲しけりゃ簡単に書けるってのもあって、 カーネルレベルスレッドを直接見せることを選んだのだった。
また、ベストなスレッドモデルがわからないうちに言語レベルスレッドモデルを 決めてしまうのが早過ぎる最適化になるということも恐れた。カーネルスレッドを 直接見せておけば、色々なスレッドモデルをその上に作って試してみることができる。
で、まあ最近の考えとしては、やっぱりカーネルスレッドを直に使うのは 面倒だなあってとこに行きつつある。とはいえ完全に隠してしまうと、 ネイティブスレッドの使い方をプログラマが管理したい場合に困る。
アプリケーションを書く時とライブラリを書く時で欲しいスレッドの抽象レベルが 違うってのが問題なんかな。アプリケーションを書く段階になると、 コアがこれだけあったらネイティブスレッドをこういうふうに割り当てて、 という勘定をきっちりしたい時がある (気にしないでいい場合も多いけど、 気にする必要がある時もあるってこと)。 一方、ライブラリを書く場合は、どういうアプリケーションが使うかまだ わからないから、なるべく抽象度の高いスレッドモデルに乗っかっておきたい。
今、futureの実装をどうするか考え始めてるんで、ぼちぼちこのへん決めないと ならないんだけれど、どうするかなあ。
Tags: Programming, Gauche
Post a comment