こける Wired-オブジェクト指向異聞-アイドルメソッドの話

更新日付 '97/05/20

さてと、アイドルメソッドの話をしましょうか。もうしばらくおつき合いくださいませ。
もう一度念を押しておきますが、前のお話と同じく、異端なオブジェクト指向です。
だから、普通の「オブジェクト指向」では、「アイドルメソッド」なんて言葉は出てきませんってばさ。
それと、このお話は「小さな組み込みプログラム」でのお話です。巨大な、または小さな「OS」や「リアルタイムモニタ」で保護されたプログラムでは当てはまらないでしょう。

ちょいと、言語定義をしておきましょう。「タスク」です。
いろんな定義があるでしょうけど、ここでは「プログラム単位」で他から「メッセージ」を送ることができ、「処理目的のために(他から見て)自発的に動作するもの」としましょう。
そして「複数がある程度無関係に並列動作できる」もので、「OSやリアルタイムモニタに管理されて自分自身が多重に動作しない(リエントラント防護されている)」もの。
Win32系だと「スレッド」がこれに当たりますか。
ちなみに、「処理目的のために(他から見て)自発的に動作するもの」は、私の造語では「タイミングメーカ」です。
タイミングを作り出すものですね。「割り込み処理」もこう考えることが出来ます。

「オブジェクト」:こいつは、「自律な」「プログラム単位」であり、他からコマンドや問い合わせを発行することができて、「状態遷移」をする事で「その場にあった動作」をする事が出来ます。
複数のオブジェクトは互いにある程度無関係に「並列動作」可能です。
そういう意味でいえば「タスク」や「スレッド」と一緒です。
なら、こいつに「タスク」の役割を負わせられないかなぁ、と私は考えました。
だって、小さな組み込みプログラムには、「OS」なんてとても載せられないし、「リアルタイムモニタ」だってきついのです。これらが必要とする資源がないんだもの。
その点「オブジェクト」ならそいう資源食いのプログラムを必要としませんし、「継承」や「多態」ができれば「タスク」なんかより便利です。
しかし、「オブジェクト」は、二つの点で「タスク」や「スレッド」に及びません。
一つは「リエントランス防護がない」。要するに、あるメソッドが実行中であっても、同じオブジェクトの別のメソッドが動作しかねない、ということです。
まぁ、そういう管理をしてくれるプログラムがないのだからしょうがないのです。
こういう管理をするには、「メッセージをキューイングする」ものが必要で、これこそが「資源食い」なのですから。
この「リエントランス防護」は諦めたとしても、まだ「オブジェクト」には「タスク」に勝てない部分があります。
それは、私の造語で「タイミングメーカ」になれない事です。
要するに、「呼び出したメソッドで動作するだけで、自発的に動作しない」のです。

例えばこんなケース。

タスクやスレッドなら、優先順位は考えなければならないでしょうが特に問題ありません。
単にメッセージを受けてから、長大な計算を続け、終了したらそのことを指定のところへ通知するだけです。
オブジェクトでも、タスクやスレッドが動的に使えるならそれを使えばいいんです。
でも、小さな組み込みプログラムは、こうしたものは使えません。
何のサポートもないオブジェクトだけでは...

または小さな組み込みプログラムならではのこんなケース。

タスクやスレッドが使えるなら最低位優先順位でこれを監視してればよいでしょう。
しかし、オブジェクトには...

「オブジェクト」に自発的に動作してほしいのです。
吉田弘一郎さんが「オブジェクトはロボットになれない」と「オブジェクト指向狂詩曲」でおっしゃってましたが、「ロボット」になってほしいのです。
小さな組み込みプログラムでも動くように、「OS」や「リアルタイムモニタ」の助けを借りずに。
はて...

ところで、組み込みプログラムのメインルーチンがどんな形をしているかご存じですか。
組み込みプログラムは大きかろうと小さかろうと、だいたいメインルーチンで「ループ」しています。
だって、Exitするわけにはいきませんもの。どこへもreturnできません。
組み込みプログラムは、基本的にループしています。

さて、このループの周期ですが、どのくらいでしょうか。
これはいろんなパターンがあります。
一仕事単位だったり、フェーズ単位だったり。
あ、一仕事単位ってのは、機械が操作されるのを待っているときから、ある操作を行ってまた操作されるのを待つまでです。
ビデオで考えると判りやすいかな。停止状態から、なんか操作して再生なり録画なりして、また停止状態に戻るまでです。
フェーズ単位ってのは、その一仕事をいくつかのフェーズに分け、各フェーズの切り替わり際で、ループを一周って事です。
「次はどのフェーズ」ってのを覚えておいて、一周するんです。フェーズのつながりが緩やかで、次のフェーズがいくつかに分かれるときにこんな事をします。

で、この「フェーズ単位で一周」をもっと細かにしたら、どうなるでしょう?
そう、「OS」や「リアルタイムモニタ」アイドル並の周期になっていくのです。1周数msecとか。
ここに、「協調によるマルチタスク」のように、処理時間を細切れにして、状態遷移を行うようにしたプログラムを複数押し込みます。
すると、擬似的な「協調によるマルチタスク」が動作し始めます。(プログラム間通信、メッセージの事は別途考えましょう。)
ここで、状態遷移を行うようにしたプログラムがオブジェクトだったら?

オブジェクトに何らかの実行をさせようと思ったら、何かのメソッドを呼ばなければなりません。即ちメッセージを送る必要があります。
普通メッセージといえば「通信」なので、何かの要求だったり通知だったり、とにかく「何か」を伝えます。
しかし、ここでは「何か」を伝えているわけではありません。無理矢理意味を込めるなら「仕事があったら仕事して」ですね。

この「仕事があったら仕事して」メッセージやそれに応答するメソッドを、私は「アイドルメッセージ」「アイドルメソッド」と呼んでいます。
こうした「アイドルメッセージ」を発行してもらえるなら、「オブジェクト」も「(他から見て)自発的に動作」できるのです。

これで、オブジェクトも「OS」や「リアルタイムモニタ」の助けを借りずに、タスクやスレッドのように「処理目的のために(他から見て)自発的に動作する」プログラム単位になりました。
「アイドルメッセージ」というひもはついていますが、吉田弘一郎さんのおっしゃる「ロボット」になれたのです。

さて、スレッドやタスクのように「自発的に活動する」オブジェクトについてお話ししました。
欠点をもう一度確認しておくと、

ということです。
これは、ソフトウェア開発、それも「工場」という現場で私が思いつき用いている方法です。
アカデミックなお人たちからは「そんなものはオブジェクト指向とは認められん」といわれるかもしれません。
でも、泥臭い「工場」という現場からの声があなたに聞こえたらと思って、お話ししてみました。

by Kok.Wish


内緒 前のお話
[表紙] [Program Files] [オブジェクト指向異聞] [プログラム未整理知識] [Winsockを使ってみようぜ] [だべり] [What's New] [書いた奴] [リンク]