プロセスその2
さてWindowsに話を戻すと、第6章(上巻P339)のタイトルが「プロセス、スレッド、そしてジョブ」というタイトルになっているのは非常に興味深い。プロセスとスレッドはごく普通に使われているが、ジョブをWindows上で普通に使ったことがある人はそういないのではないか、と思う。ジョブの説明は6.6節(上巻P427)からに詳しいが、94ページを費やす第6章の中で、ジョブが占めるページの割合はわずかに5ページ弱というあたりが、Windowsの中に占めるジョブの重要性を如実に表わしている気がするが、実際普通に使っている分にはあんまりお馴染みではない。ジョブとは1つ以上のプロセスを組み合わせて管理する「作業の単位」ということになるが、普通に使う分には「1つの作業」＝「1つのプログラム」＝「1つのプロセス」となるだろう。つまり、複数のプログラムを組み合わせて、まとめて実行するのがジョブというわけだ。この概念は、恐らくVMSから持ってきたのだろうと想像される。理由は2つある。
一つは、VMS自身がJobという概念を持っており、しかも多用していたことだ。このJobという概念は別にVMSの発明ではない。恐らくはIBMなどメインフレームのバッチ処理系から概念を流用したものと思われる。直接的には、VAXの前世代にあたるPDP-11などで動くRSXなどのOS上で既にJobという概念があったから、ここから持ってきたのだろうが、ではRSXとかのJobはどこから? というと、恐らくはIBMのOS/360やその後継OSからアイディアを借用したのではないか、と思われる。バッチ処理、という言葉に馴染みのある人はもうだいぶ少なくなったと思うのだが、イメージ的にはUNIXのCronとかにやや近いものがある。たとえば昔の店舗の販売管理を行うシステムでは、毎日の営業時間後に、
- 各POSから売り上げデータを吸い上げる。
- そのデータを元に、当日の〆処理を行う。
- 決済データを本店に送る。
- (2)のデータを元に、在庫数の更新を行う。
- 在庫数のデータを本店に送る。
なんて事をやっていた。バッチ処理の場合、(1)～(5)はそれぞれ別のプログラムに分離しており、バッチ制御プログラムはスタートすると
- (1)を実施する。
- エラーが無ければ(2)と(4)を実施する。
- (2)が終わったら(3)を実施する。
- (4)が終わったら(5)を実施する。
- (1)～(5)が終わったらレポートを出力して終了
なんて調子で動いていた。実際IBM系のOSの場合、このジョブ制御を行うための専用言語(JCL:Job Control Language)なんてものまであった。VMSのJobもこれに近いものがあり、複数のプログラムを順次あるいは同時に動かし、そのステータスを受け取って分岐するといった作業が可能になっている。このJobという概念は、Windows環境ではかならずしもそぐわない。というのは、Windowが立ち上がり、そこでインタラクティブ処理を行うというのが一般的なプログラムの作法になっているからで、根本的に相容れないものではある。勿論全てのプログラムにWindowが出るわけではない(システムサービスとして動くプログラムは当然Windowなど表示されないし、OS Kernelとして動くプログラムもやはりWindowなんぞ無い)が、ただそうはいってもスクラッチから構造を考えた場合、Jobという概念を導入する必然性は薄いといわざるを得ない。にもかかわらず、Jobという概念が厳然と存在するのは、VMSから継承した公算が高いと思う。
もう一つの理由は、Jobという名前そのものである。リアルタイムOS系とかでは、こうしたものを"Job"ではなく"Task"と呼ぶことが多い。実際これだって「タスクマネージャ」なのであって、「ジョブマネージャ」ではない。実際意味合い的にはTaskもJobも大した違いは無く、強いて言えばJobはやや古い呼び方でTaskの方が最近っぽいという程度だ。だからこそ、あえてここにジョブという名前で概念を導入したことに、やはりVMSの影響を強く感じる。
次に、VMSにおいてJobとProcessの関係を説明したい。(続く)
