マルチ・スレッド(multi-thread)プログラミングの落とし穴、その1(かもしれない)
プラダを着たiPhone

優秀な主婦はイベント・ドリブン(event-driven)方式でパンを焼く

Sunset06 昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。

1.イーストを30℃のお湯と一つまみの砂糖とまぜて15分間予備発酵させる
2.ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる
3.こね板の上で生地をこねる
4.ボールにラップをして室温で1時間発酵させる(一次発酵)
5.適当な大きさに生地を分割し、丸めて形を作る
6.オーブンに入れ、30分発酵させる(二次発酵)
7.オーブンの温度を200度にして18分焼く

 これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である(その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている)。

 興味深いのは、このレシピにおける、「15分予備発酵させる」だとか「18分焼く」などの待ち時間を含むステップだ。

 ブクブクとあわ立ってくる予備発酵中のイーストを15分間じっと見続けていたり、パンが焼け上がるまでオーブンの前に座り込んでいるのは、初めての「パンを焼き」にチャレンジしている日曜日のお父さんぐらいで、いつもたくさんの仕事を同時に抱えた普通の主婦(もしくは主夫)は、そういった待ち時間を利用して、洗濯をしたり、夕ご飯のおかずを作ったり、韓国ドラマを見たり、子供を幼稚園に迎えにいったり、家計簿をつけたりしているものだ。

 そんな複数の仕事を同時にこなしている彼女たちにしてみると、自分がそれぞれの仕事のどのステップにいるか(つまりcontext)を常に完璧に把握しておくことは不可能に近い。手続き型のレシピのままで作業をしようとすると、それぞれの仕事において自分が何をしておくのかを把握しておくだけで頭がパンパンになってしまうし(memory overflow)、頭の切り替え(context switch)にやたらと時間がかかって作業効率が落ちてしまうからだ。

 そこで、パンの発酵中にはタイマーをしかけておき、タイマーが鳴ったところで「あ、キッチンでタイマーが鳴ってる。えっと、何のタイマーだっけ。そうだ、そうだ、パンの二次発酵中だったんだ。じゃ、次はオーブンの温度を上げてと…」というイベント・ドリブンな仕事の仕方をしているのだ。

 言い換えれば、彼女たちの頭の中では、上の「手続き型のレシピ」が、以下のような「イベントに応じた作業(event handler)」の集まりである「イベント・ドリブン型のレシピ」に変換されて実行されているのだ。

【スタート】
1.イーストを30℃のお湯と一つまみの砂糖とまぜてタイマーを15分間にセットする(予備発酵)
2.他の仕事に移る

【予備発酵終了のタイマーが鳴る】
1.ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる
2.こね板の上で生地をこねる
3.ボールにラップをし、タイマーを1時間後にセットする(一次発酵)。
4.他の仕事に移る

【一次発酵終了のタイマーが鳴る】
1.適当な大きさに生地を分割し、丸めて形を作る
2.オーブンに入れ、タイマーを30分後にセットする(二次発酵)
3.他の仕事に移る

【二次発酵のタイマーが鳴る】
1.オーブンの温度を200度にしてタイマーを18分後にセットする
2.他の作業に移る

【焼き上がりのタイマーが鳴る】
1.焼きあがったパンをオーブンから取り出す。(パン焼き終了)
2.他の作業に移る

 実際には、これに加えて、他のさまざまな仕事から派生した「イベントに応じた作業」が記述されたプログラムの断片が、彼女たちの頭の中にはぎっしりと詰まっているのだ。例えば以下のようなもの。

【洗濯終了のタイマーが鳴る】
1.洗濯機の中のものを乾燥機に移してタイマーをセットする
2.他の作業に移る

【赤ん坊が泣き始める】
1.おなかが空いている時間ならミルクをあげる。そうでないならば、オシメが濡れてないかチェックする。濡れていれば交換する。
2.他の作業に移る。

 イベント・ドリブン型の利点は、それぞれの「イベントに応じた作業」が規格化・単純化されてているため、仕事の量がどんどん増えて行ったとしても、仕事の量に応じて忙しくなるだけの話で、それ以外のオーバーヘッドがとても少ない点だ(=linear scalability)。それぞれの「イベントに応じた作業」さえキチンと書かれていれば、その集まりには順番も秩序も必要がないので、色々な仕事のための「イベントに応じた作業」がごちゃごちゃに頭の中で混ざり合っていても何とかなってしまう点(system stability)もこの方法の利点である。

 つまり、これがソフトウェアで言うところの、「手続き型のプログラミング」と「イベント・ドリブン型のプログラミング」の違いである。手続き型は一連の作業の流れを把握するという意味ではとても分かりやすい記述の仕方だが、同時にいつくもの仕事を抱えてこなして行く時には、イベント・ドリブン型で処理した方が効率が良かったり、システムとしての安定度が高まるケースがある、という点が注目すべき点である。

Comments

akion

かつて優秀だった主婦も年老いて処理能力が下がっているのに元のままのつもりで作業を始め、アラームが鳴っても元の作業に復帰できずにパンは過発酵、洗濯機の中で皺くちゃのまま洗濯物が生乾き、そういやオシメ換えた後に手を洗ってなかったよな…と、すべて台無しな状態を醸し出したりして、手続き型に戻れと言うこちらもなんだか寂しい現実を思い出してしまいました。
能力に見合った方式を見つけるのが重要なんでしょうね。そういえば、うちの洗濯機のタイマーは終了時間(ex.3時間後に乾燥まで終わる)を指定するようになっていて、他の家事とのスケジューリングが事前にできて素晴らしいと思いました。

えーちゃん

会社員でも、忙しいとイベント・ドリブンになりがちです

無限にリソースがあるならば、手続き型で、戦略を立て、戦術にそって 一つ一つを成し遂げながら たくさんのことを 同時多発的に処理していける。でも、実際には 限られたリソースで電話や会議や緊急メールなど、突発的に起きるイベントに立ち向かわなければならない。だから、コンテクスト・スイッチのことは忘れて、今目の前にある危機を処理していくことになる。

でも、会社の場合は、時々 手続き型に立ち返って、戦略・戦術を練り直し、自分以外のリソースにコンテキストを割り振り、あるいは取捨選択しながら仕事していくところが違うかなぁ。イベント・ドリブンだけで仕事してたら、本当にやらなきゃならないことを見失ってしまうから。

話は本筋から離れるけど、自分が作るパンは 自然界の酵母を使うので、発酵時間が読めません。優秀な主婦でもないので、結構 つきっきりです。パン作りはプログラミングと一緒で、少ない種類の優れた材料(命令セット)を組み合わせて (同じものを与えられても)人と違うもの(アプリやサービス)を作れるのが面白いと思っているのです

rero

> あ、キッチンでタイマーが鳴ってる。えっと、何のタイマーだっけ。そうだ、そうだ、パンの二次発酵中だったんだ。
この理解の過程がまさにコンテキストスイッチのオーバヘッドに相当するもの.
さらに,複数のイベントを覚えておくことも,結局コンテキストを覚えておくのと同じ.
これは本質的に同じものを単に違うパラダイムで表現しただけのように見える.

masato

簡単なアナロジー、プログラマにも参考になります。
ところで、イベントベースは、かっこいいのですが、何か問題があったときに非常に苦労します。
たとえば、タイマ設定を間違えたら?イベントの設定を間違えたら?デバッグで、ステップ実行ができないなど、問題時の解析が難しい?複数のイベントを同時期に受けたらなどの机上解析の難しさ?

Yumiko

本当に優秀な主婦は

どんなときも「それぞれの仕事において自分が何をしておくのかを把握しても頭がパンパンにならずに(memory overflow)、頭の切り替え(context switch)ができる」人だと思うのですが、どうでしょうか。

そのためにはそれぞれのタスクに精通していて、おまけにすべてのタスクのフローが見えていなくてはならないようです。そういう本当に尊敬できる主婦の方を何人か知ってますが、私自身はイベントドリブンどころか、ドラマを見始めたら何時間もやめられないアナログな主婦です。

みゅう

> あ、キッチンでタイマーが鳴ってる。えっと、何のタイマーだっけ。そうだ、そうだ、パンの二次発酵中だったんだ。

これって人が無意識のうちに瞬時に行ってることを
わかりやすく、プログラム的な形で表現してるのだと思いますよ。
何かの用事で自宅からタクシーを送迎させたときに、通りで待っていると伝えたからって車がくる前から望遠鏡でタクシーの姿を見張ってたりしないですよね?w
車が到着するまでの数分間は忘れ物がないか?とか、先方と連絡をとってみたり、予定を確認したりと、いろいろしてるわけです。
当然車が近づいてくればエンジン音なりクラクションなりで気が付くわけですが。
この「気が付く」という部分をわかりやすく具体的に記載しただけで、屁理屈を言う部分ではないと思いますよ。
同じタクシーを使っていくつかの客先を回ったとしても、すべて回る順序を覚えてる人もいれば一度の談話の内容が濃く、予定をいちいち覚えていれなくて、確認する人もいるでしょうて。
僕から見たらひじょうにわかりやすく説明されてると思います
ご不満でしたらそこからもう一歩上の場所にご自分でいかれてはいかがですか?
でも、こういった事情を、あなた自身が初心者の方に説明するのは絶対に無理だと思いますが。w

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)