Well done arlitce that. I'll make sure to use it wisely.
* KH-FDPLのノート0005
-(by [[K]], 2015.03.18)
** (1) マルチスレッドについて
-KH-FDPLでは、一つのVMで複数のアプリを並列で動作させる仕組みを持たせようと思っています。しかしそれはいわゆるマルチスレッドとは微妙に異なります。
-どう異なるのかの説明はあとに譲って、まずはなぜそのような並列動作を実現させようと思っているのかを説明させてください。
-並列動作ができれば、アプリAの実行中にオブジェクトが変わっていく様子をアプリBが参照したりできるようになります。これはデバッグにも、プログラムの学習の様子を理解するのにも、大変有効だと思います。
-さらにこれはOSのマルチスレッド機能を使うものではなくて、KH-FDPLが自分のCPU時間を切り貼りして実現するものです。ですからスケジューリングなどもOSに依存することなく、共通に行えます。したがって、OSがマルチタスクやマルチスレッドに対応していなくても、KH-FDPL内ではマルチタスクができます。
** (2) KH-FDPLでのマルチスレッドの方法
-まずKH-FDPLではCPUにコアが複数あっても、その中の一つしかアプリの実行に割り当てません。要するに、単に内部で切り替えながら実行しているだけです。これで「同時に複数のアプリが実行して競合してしまう」問題を回避します。
-またアプリは不意にスレッド切り替えを食らって、オブジェクトを中途半端な状態にしてしまう、という懸念がありますが、これもKH-FDPLでは基本的に生じません。というかそもそもlock命令がKH-FDPLにはないのです。ロックを掛けてオブジェクトの整合性を守るのではなくて、check-point命令（仮称）が来た時にスレッドを切り替えるのです。
-つまり起動時からずっとlockみたいなもので、check-point命令というのは、unlock+lockみたいなものです。だからcheck-point命令を入れ忘れると、全くスレッドが切り替わらなくなって強制停止させるしか方法が無くなります。・・・でもそれでいいのです！ それがいやなら、check-point命令を好きなだけ入れてください。それだけのことです。
-こうすることで何が嬉しいのかというと、lock入れ忘れによる悩ましいバグが無くなるのです。初心者にlockはつらいだろうと私は思うのです。check-point命令の入れ忘れは簡単に気付けます。この処理をしている間、他のアプリの反応が悪くなるんだよなー、とか。また、KH-FDPL側もこのアプリは最大で○○ミリ秒間、check-point命令を実行しない期間がありました、みたいな報告をくれます。

-時間のかかる処理をするライブラリ関数があったとして、その処理中にcheck-point命令を勝手に実行してもいいのかいけないのか、という問題がありえます。それはどっちにするのかをフラグで制御できるべきです。逆に引数にそういうフラグがあれば、この関数はそういう配慮があるんだということも分かります。
-これに対して、lock命令的なものを作り、これがあるとunlock命令が来るまでcheck-point命令を無視する、という仕様も可能ですが、これだと関数が配慮していることに気付けませんし、自分も配慮しようとしなくなるでしょう。それは教育的ではないと思います。



** (3) lockモデルが好きな人は
-でも初心者以外はlock方式のほうがいいかもしれません。結構なことです！それならそういう言語を作りましょう。その言語は、デフォルトで毎行行頭にcheck-point命令を付与したバイトコードを生成します。でもlock期間はその付与を抑制します。それでいいでしょう。
** (4) マルチコアなんだから・・・
-マルチコアなんだから全部のコアを使って実行させたい、性能が出てほしい、・・・その望みは正当だと思います。
-それならC++やJavaなどを勉強して、マルチスレッドなプログラミングパラダイムを勉強して、夢をかなえましょう。・・・KH-FDPLとしては、そういう割りきりでいます。
-まあコアの数だけKH-FDPLを起動して、それぞれで独立してアプリを起動してもいいですが（笑）。


* こめんと欄

#comment
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS