OS/2がやってきた(その2)（月刊ASCII 1988年2月号7）

前回の続きで「OS/2がやってきた」をスクラップする。

人間とOS/2の会話
　コマンドプロセッサのプロンプトから,コマンドなどを入力して作業をするような通常の操作では,OS/2のマルチタスク処理がユーザーの目にふれることはほとんどない。
　タスク切り替えは,システムの水面下ですみやかに行われる.したがって,タスク切り替えのタイミングは,ユーザーにとっては完全に透過であり,タス切り替え処理によってユーザーが戸惑うことはない。
　OS/2のマルチタスク機能をユーザーが意識できるのは,Session Managerを通して,バックグラウンドで動作中のアプリケーションプログラム(タスク)を,フォアグラウンドに呼び出す際に行われるコンソール画面の切り替えのときのみである.
　このSession Managerは、OS/2のユーザーインターフェイスの重要な部分を担うOS/2のコンポーネントのひとつで、ユーザーは、このSession Managerを使用して,同時に実行しているすべてのアプリケーションプログラム(タスク)を管理することになる(コラム3).
　OS/2のタスクの呼び出しと画面切り替えは,Session Managerによって「仮想スクリーン」と「スクリーングループ」という概念の上に実現されている(コラム4).

34年後に読むと冗長な説明だが、当時まだOS/2を見たことも触ったこともないから、この説明を読んでもチンプンカンプンだった。記憶に残っていない。

コラム3
Session Manager
　OS/2上で実行されているアプリケーションプログラム(タスク)は、OS/2によって,コンソールの占有を許されるまで,ユーザーのキー入力を受け取ることができない.また,そのコンソール画面に対する表示データも見ることができない。
　すなわち,プログラム(タスク)は,ユーザーから呼び出されたときに,コンソール装置に対する制御権が与えられる.そこで,表示データがスクリーンに表示され,はじめてユーザーと会話することが可能になるのである。
　OS/2では,このようにユーザーが,実行中のプログラム(タスク)のうちのひとつを選択し,コンソールへ呼び出して会話することを「セッション」という。
　そして,コンソールと,あるタスクを結び付けることを「セッションを確立する」という.Session Managerは、このセッションを確立する機能を提供する.

タスクとか、セッションとかよくわからないままWindowsを使ってきた。習うより慣れろだった。こうしてOS./2の解説を読むと当たり前だがよくわかる。

コラム4
仮想スクリーンとスクリーングループ
　複数のプログラムを1台のコンピュータ上で同時に実行すると,ひとつしか存在しないコンソール装置に対して,複数のプログラムが,同時にデータの表示やキーボードの入力を実行するという矛盾が発生する。
　この矛盾を解消して安全な操作環境を実現することは,すべてのマルチタスクO.S.のもつ課題でもある.
　OS/2は、この課題を「スクリーングループ」という手法で解決している.
　このスクリーングループには、必ず「仮想スクリーン」,「仮想キーボード」,「仮想マウス」で構成される仮想的なコンソール装置が割り当てられている。
　OS/2のプロセスは,必ず,このスクリーングループのもとで実行される.したがって、プロセスが出力するコンソールへの表示データは,まず,そのプロセスが属するスクリーングループの仮想スクリーンに書かれることになる.
　仮想スクリーンに書かれたデータは,その仮想スクリーンが「実際のコンソール装置(物理スクリーン)」に割り当てられるまで表示されない。同様に,仮想キーボードに対して入力を要求したタスク(スレッド)は,仮想キーボードが「実際のキーボード装置(物理キーボード)」に割り当てられるまで実行を中断されることになる。
　スクリーングループの作成は,Session Managerを介して,新たなコマンドプロセッサCMD.EXEを起動したときに行われる。
　そして,そのCMD.EXEによって起動されるアプリケーションプログラムは,CMD.EXEと同一スクリーングループのプロセスとして実行される.また,アプリケーションプログラムが実行するプロセスも,やはり,同じスクリーングループに属することになる.
　このようにしてOS/2では,複数のプロセスが,ひとつのスクリーングループを構成していくのである.
　Session Managerは,スクリーングループに実際のコンソール装置を割り当てる役割(セッションの確立)を果たす.
　すなわち,バックグラウンドタスクとフォアグラウンドタスクの切り替えを行う。

プロセスとスレッドによるマルチタスク処理
　ここまでは,OS/2の操作環境から見た全体像を解説してきた.
　最後に,OS/2のプロテクトモードで実行されるアプリケーションプログラムの側から,OS/2を眺めてみることにする。
　OS/2は,「プロセス」(Process)と「スレッド」(Thread)という,2つの概念のもとでマルチタスク処理を実現する.
　この2つのシステムオブジェクトは,OS/2のプログラミングスタイルに大きな変化を与えるものである.プロセスとスレッドの関係は,互いに絡み合って少々複雑である.プロセスとスレッドは,次のように定義することができる.
プロセスはひとつ,あるいは複数のスレトッドで構成されるものである.
スレッドとは,ある処理を実現するサブルーチン,あるいは,関数の集合である.
　すなわち,「プロセス」は、MS-DOSのプロセスと同様,実行時にディスクからメモリにロードされるアプリケーションプログラムの単位であると考えられる.
　そして,「スレッド」は、OS/2によって実行されるタスクの単位である.OS/2は,タスクのスケジューリングを,この「スレッド」を単位として行うのである.言い換えれば,OS/2が実行するのはスレッドである.
　プロセスは、OS/2でもMS-DOSと同様に,コマンドプロセッサや,アプリケーションプログラムから,ファンクションコール(DOSEXECPGM:MS-DOSでは,ファンクション4BHに相当)を使用して起動することができる.
　このとき,OS/2がプロセスの起動時に制御を渡すエントリポイントが「主スレッド」である.C言語で書かれたプログラムであれば,main関数が,この主スレッドにあたる(この主スレッドしかないアプリケーションプログラムは,MS-DOS上のアプリケーションと同様のプログラム構造になる).
　実行が開始された主スレッドは,各種のファンクションコールを用いて,OS/2に様々な要求を行いながら処理を実行する.
　そして,処理を終了したときには,プロセスを終了するファンクションコール(DOSEXIT)を発行して,自分自身を終了させることができる.
　また,主スレッドは、ファンクションコールを使用して,同じプロセス内の別のスレッドを起動することができる.起動されたスレッドは,起動したスレッドとは非同期に,並列的に実行されるようになる.
　こうして,同一プロセス内の複数のスレッドが同時に実行されるようになる.
　主スレッド以外のスレッドは,C言語ではひとつの関数として書く.
　したがって,主スレッド(main関数)から,ある関数をスレッドとして並列実行する場合は,その関数のアドレスと,関数がスレッドとして動作するときのスタックのアドレスなどを指定して,スレッドを起動するファンクションコール(DOSCREATETHREAD)を発行すればよい。
　DOSCREATETHREADファンクションコールによって,並列的に実行されるスレッドは,同じデータセグメントあるいはコードセグメントを共用(注3)する.このため、複数スレッドが静的変数などのデータを共用するときには,互いに排他制御を行う必要がある.また,各スレッドは,プロセスが所有するシステム資源――たとえば,オープンされているファイルやプロセス間通信(注4)のためのセマフォ(注5),待ち行列(注6)など――も共有している.

注4:
　マルチタスクシステムでは,並列的に実行されるプロセス間で,多種多様な情報を受け渡して処理をしたいという要求が発生する.この複数プロセスの間でデータのやり取りを行うことを、プロセス間通信(Inter-Process Communication:IPC)という。OS/2では、プロセス間通信の手段として,セマフォパイプ,待ち行列の3つの方法を提供している。

注5:
　セマフォは、プロセス間通信機構の中で最も高速な手段である.
　OS/2におけるセマフォは,オンとオフの2つの値をとるフラグオブジェクトである.アプリケーションプログラムは,ファンクションコールを使用し,セマフォに対して,「セット」,「クリア」,「テスト(状態の検査)」などの操作を行うことができる。
　このセマフォは,複数のプロセスで、同時にアクセスすることができないシステム資源の排他制御などに有効に動作する.
　あるプロセスが,セマフォに対して「セット」を要求すると,他のプロセスによって,そのセマフォがすでに「セット」されていれば「クリア」されるまで,「セット」を要求したプロセスは実行を中断される.
　以上のように,複数プロセス間で同期をとるには,高速で有効な手段である.しかし,メッセージなど大量なデータを扱うことはできない.
　「RAMセマフォ」と「システムセマフォ」の2種類あり,RAMセマフォはスレッド間の通信に使用し,システムセマフォはプロセス間の通信に使用する

注6:
　待ち行列(キュー)は,もっとも強力な汎用性の高いプロセス間通信手段である.待ち行列は,名前を付けて生成したり,複数のプロセスからオープンしたり,クローズすることができる.
　また,待ち行列に対して読み書きすることで,任意のプロセス間で,任意の大量なデータを通信することができる.
　しかし、内部処理の複雑さから、処理速度はパイプに比べて遅い。セマフォとは比べものにならない。
　パイプは、密接に関連した(たとえば,親プロセスと子プロセス)プロセス間の通信に使用する。セマフォと違って,任意の型のデータを交換することができる.プロセスから見ると,パイプへの入出力は,ファイルへの入出力と同じように見える.
　このパイプのもっとも一般的な使用方法としては,標準入出力をパイプに対する入出力にリダイレクションする方法がある.
　たとえば,標準入出力をパイプに切り替えて,子プロセスを起動すると,子プロセスの標準入出力は,自動的に親プロセスを相手にしたプロセス間通信となる。
　待ち行列に比べて,交換できるデータ量は少な|い(65504bytes以下)が,セマフォと同様,メモリ上に作成されるオブジェクトであるため,通信速度は比較的高い.

　以上のように複数のスレッドが,ひとつのプロセスの中で並列的に実行されるようなアプリケーションプログラムのプログラミングは、細心の注意と高度な技術を要する最も複雑なプロセスとなる.しかし,このタイプのプログラムは,OS/2が提唱する典型的なマルチタスクのプログラミングスタイルであるといえる.

この辺の概念が未だに分からない。使っていないのだから当たり前だ。特にセマフォは言葉の響きが良くて妙なあこがれがあった。使ってみたいものだと思っていたが、プログラムを作っているとき知らずにその概念を使っていた。

今後の連載予定
　様々な憶測や期待の中で、姿を現した本格的なマルチタスクO.S.であるOS/2は,ユーザーインターフェイスにおいては,MS-DOSを基本として、無理のないマルチタスク環境を提供している.
　このOS/2が提供する操作環境は、MS-DOSのユーザーであれば最小限の努力(学習)で,現在のMS-DOSよりはるかに強力で快適な,独自の操作環境を,難なく実現できる可能性を秘めている.
　しかし,本項の最後でも解説したように,アプリケーションプログラムとのインターフェイス(マルチプロセス,マルチスレッド)については,これまでのMS-DOSプログラマに対して,そのプログラミングスタイルを大幅に考え直さなければならないテーマを数多く含んでいる.OS/2は,その専用アプリケーションが数多く誕生したときに,より強力な真価を発揮するものであることはいうまでもない.
　その意味において,本連載には、MS-DOSアプリケーションのプログラミングに精通したプログラマが,OS/2でのマルチタスクアプリケーションのプログラミング知識をより容易に理解し,そのアプリケーションプログラムが,早期に数多く作成されるために少しでも役立てばという願いが込められている.
　次回は,マルチスレッドで動作する簡単なプログラムを例に,OS/2でのアプリケーションプログラムのプログラミングを中心に解説する予定である.
　また,そのプログラミング例をもとにして,OS/2とのインターフェイス(Application Programing Interface注7)の解説や,OS/2(プロテクトモード)におけるプログラミングスタイルと、MS-DOSのそれとの比較も行ってみしたいと思っている。

注7:アプリケーション・プログラミング・インターフェイス(API)
　OS/2環境で動作するアプリケーションを開発するために用意されているユーザープログラムインターフェイスを「API(Application Programing Interface)」という。これはMS-DOSのファンクションコールに相当するものであり,関数の形で提供される。
　すなわち,MS-DOSのファンクションコールが,INT命令によるソフトウェア割り込みであるのに対して、OS/2のAPIはCALL命令による関数呼び出しで実現される.
　このAPIには、デバイスドライバを書くための機能も含まれている.なお,API関数は,C言語からも直接呼び出すことができる.

なるほど「,本連載には、MS-DOSアプリケーションのプログラミングに精通したプログラマが,OS/2でのマルチタスクアプリケーションのプログラミング知識をより容易に理解し,そのアプリケーションプログラムが,早期に数多く作成されるために少しでも役立てばという願いが込められている.」だったのか。これでは、私が当時読み込み理解するのは困難だった。今はプログラムを作らなくともOS/2の概念は理解できるようになった。