[ruby-dev:43993] Re: ThreadGroup#make_local_space!

永井＠知能．九工大です．

From: Urabe Shyouhei <[e-mail]>
Subject: [ruby-dev:43983] Re: ThreadGroup#make_local_space!
Date: Tue, 28 Jun 2011 21:25:21 +0900
Message-ID: <[e-mail]>
> > 基本的には束ねるものでしょうね．
> > これまでは機能が少なすぎて，sub thread が自動的に含まれることを除き，
> > thread を array に入れて管理するのとたいして変わらなかった，
> > それゆえ，わざわざ使う気にもならなかったというように思います．
> 
> いいえ。Threadを束ねて使うという面ではむしろ現在のThreadGroupは配列より
> も退化しており、積極的に忌避されます。少なくとも束ねたはずのスレッドが知
> らぬ間にどっかに行ってしまうようなものを、私の感覚では束ねたとは言いません。

ThreadGroup#enclose は束から逃さないためのものですよね．
終了した thread が勝手に消えることをおっしゃっているのであれば，
それは利点でもあり欠点でもあるでしょう．
これまでは監視用の thread を用意するなどしない限り
終了した thread をうまく捕獲する手段がありませんでしたが，
thread_queue を用いれば，thread のリストをチェックしなくても
thread の終了順に処理できます．
配列の各 thread を join で待つ場合は，
単純にはその配列の order でしか処理できません．
確かに終了した thread でもどこかに消えることなく配列に残りつづけますが，
死んだ thread の再活性化ができない以上，終了チェック後は不要なはずで，
終了したものをいつまでも保持しておかねばならない理由がわかりません．

> > ThreadGroup の機能強化により，ThreadGroup というものの活用の幅を広げ，
> > ひいては thread 活用プログラミングの幅も広げられないかというのが趣旨です．
> > 「そうは見えない」というのであれば，それは私の力不足ということです．
> 
> これは意欲的でよいと思いますが、もう少し具体的になるとなおよいです。ス
> レッドプログラミングはパラダイムとしてははるか四半世紀前には存在していた
> わけです(Mach microkernel)。今更どう広げようと? メソッド用意しとけば勝手
> に広がるというのはさすがに目論見が甘いので、そうは思っておられないので
> しょうが...

あくまでも Ruby の上での話です．
さすがにパラダイムとしてのスレッドプログラミングを
どうこうしようなどとという大それたことは考えておりません．
これまではできなかった，あるいは余計な手間やコストがかかっていた処理を
楽に書けるようになれば，利用の機会も増えるのではないかとは考えています．
強化案のメソッド群は，過去に thread を使っていろいろとやっているときに
「こういうのがあればもっと積極的に ThreadGroup を使うのに」
と考えたものが中心となっています (「ついでに」というものが複数含まれて
いるのも事実ですが)．
そうした実例，具体例が不足しているという批判は，
少なくとも現時点で確かにそのとおりで，否定できせん．

まぁ，Ruby の thread そのものが使われなくなるだろうということであれば，
ThreadGroup の強化など無意味なこととなります．

> > ThreadGroup オブジェクトに持たせようとする thread_queue は，
> > thread 群の監視能力の強化を図るという意味合いがあります．
> > thread pool コントロールの主導権を監視側に移すことが可能となります．
> > 例えば thread 群が処理能力差のある別マシンに処理依頼をする場合でも
> > 各 thread が処理完了に要した時間を監視し易くなりますから，
> > スケジューリングもより緻密にできるかもしれません．
> 
> これは本当にThreadGroupを用いて実現する機能ですか?
> たとえばスレッドが処理に要した時間をどこかに持っておくとすれば、当然その
> スレッド自信が知っているのが自然と思いませんか? なぜThreadGroupをわざわ
> ざ用意する必要があるのです?

もちろん時間自体は thread に個々に持たせておいて問題ありませんし，
元々，ThreadGroup 自体が時間情報を保持するなどとは言っていません．
thread 自体は他の thread との比較なんて知らないでしょうから，
スケジューリングを管理する thread がその情報を用いて判断するだけです．

# 優先判断まで thread 自身にやらせることも不可能ではないでしょうけれど，
# それはいくらなんでも個々の thread の担当範囲として大きすぎますよね．

で，その管理 thread がどのように処理判断するかなのですが，
thread 群を配列で持ち，それをスキャンして決めるという方法も可能でしょう．
その場合，スキャンするタイミングをどうするかという点で，
thread queue のようなものがないと一定周期でチェックにいく処理に
なりそうに思いま … したが，予期せぬエラー終了を考えないなら
処理 thread から監視 thread を run するような方法で可能ですね．

# 処理 thread が主導権を握っているのが気に入りませんが．

監視 thread 側が，処理 thead の実行完了の都度，それに対処できれば，
スケジューリング管理も簡潔になるのではないかと考えていました．

タスクごとに二重 thread (実行 + 監視) となるコストを気にしないのなら
(sub-thread 生成もすべて監視に必要な処置が施されているという前提で)，
thread queue として使う queue を自分で作ることは不可能ではありません．
それで十分だというのであれば，ThreadGroup の thread_queue などは
無くても良いということになるのでしょう．

私自身は無駄な thread を必要とするのは嬉しくないし，thread queue の
枠組が用意されていれば楽になるので嬉しいと考えています．

> たとえば似たような問題意識としてclassboxとか呼ばれるものがあって、すでに
> trunkにはModule#mixという機能が入っているわけですが、ご存知でしたか? メ
> ソッドの可視性の変更をModuleで実現するというのはきわめて自然な発想です。
> Moduleはそのためのものですからね。しかるに、Module#mixではなく、
> ThreadGroupに機能を追加する、なぜですか。なぜModuleではないのですか。

実行単位である thread を固有環境の単位として考えているからです．
良い説明が出てこなくて悩んでいるのですが，
Module への装備が言語環境のレベルで箱庭を用意するのに対し，
ThreadGroup への装備は実行環境のレベルで箱庭を用意するとでも
言えばいいのでしょうか．

Module#mix についてはきちんと理解できているとは言えないので，
その機能限界についてもわかりません．
ただ，ここで考えている ThreadGroup の固有環境とは少し対象領域が違い，
並立できる存在であるように思います．

> > これらの問題のすべてを safe level の拡張で対処できるとは思えません．
> > 仮に safe level からのアプローチで解決を図るとしても，
> > ThreadGroup が管理単位となって make_local_space! のようなものが
> > 必要になるだろうと予想します．
> 
> なぜですか。
> 
> > ならば，safe level と無関係に有効に使いうる make_local_space! を実装し，
> > それと組み合わせて safe level の機能強化を考えるのも不自然とは思えません．
> 
> いいえ不自然です。なぜThreadGroupにそのような機能が必要ですか?

safe level は thread や block のような実行環境寄りに設定されるものです
ので，動的に変更可能な枠組でなければどこかで無理が出るように思います．
もちろん Module において binding よる変更は可能ですが，
実行環境としての binding の完全移行を行うのは無理矢理感が漂います．
例えば実行中の thread が自身の土台たる binding を変更可能にするのは
言語仕様として無茶であるように思います．
そうでなければ module_eval や binding を指定しての eval などによるか，
新たな binding で thread を生成して自分は死ぬかのようなことになるので
はないでしょうか．
前者は一時的な変更にしかなりませんから，元の実行環境に戻ってしまいます．
後者は新たに実行し直しているわけですから，「移行」とは違いそうです．

固有環境を持った thread が sub thread を生成して処理を行うとき，
sub thread は親 thread と共通の環境を引き継ぐことを求める場合が多い
のではないかと思います．
sub thread を生成するたびに固有環境のコピーを作るのは無駄ですので，
デフォルトで引き継がれる ThreadGroup が固有環境情報を持っているのが
効果的だろうという考えです．
-- 
永井 秀利  ([e-mail])
九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教