JPH04215136A - 周辺装置マネジャ、マルチタスクデータ処理システムおよびインターフェース方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データ処理システムに
関するものであり、具体的には、ディスプレイ・アダプ
タを含むデータ処理システムのソフトウェアによる管理
に関するものである。

【０００２】

【従来の技術】現在の表示アダプタは、複数のポートへ
のアクセスを提供する能力を備えている。これは、１つ
の表示アダプタに、実際に２つの別々にアドレス可能な
ポートを介してアクセスできることを意味している。こ
れによって、アプリケーション・プログラムは、表示装
置にアクセスする際に、どちらか一方のポートを参照で
きるようになる。

【０００３】この分野の技法の従来技術には、フォール
ヒース（Ｖｏｏｒｈｉｅｓ）、カーク（Ｋｉｒｋ）、ラ
スロップ（Ｌａｔｈｒｏｐ）の論文、“Ｖｉｒｔｕａｌ
　Ｇｒａｐｈｉｃｓ”，　ＣｏｍｐｕｔｅｒＧｒａｐｈ
ｉｃｓ，Ｖｏｌ．２２，Ｎｏ．４，１９８８年８月があ
る。この論文は、単一のタスク本位のグラフィックス・
ディスプレイ・アダプタを含む多重プロセス・ワークス
テーションを対象としている。この論文は、ディスプレ
イ・アダプタのコンテキストを速やかに切り替える問題
を対象としている。これは、グラフィック所有権違反（
あるグラフィックス・プロセスが、アクセス権を持たな
い装置にアクセスを試みた）の検出に基づくコプロセッ
サ例外、ハードウェア内での描画コンテキストの効率的
なスワッピング、コマンド・フロー制御に基づく例外、
ウィンドウ境界内での描画のクリッピング、および画素
フォーマットと画素用ルックアップ・テーブルの切替え
を用いることで達成される。この参照文献は、追加のハ
ードウェアが、ディスプレイ・コンテキストの速やかな
切替えという問題の部分的解決策となることを教示して
いる。

【０００４】ローデン（Ｒｈｏｄｅｎ）　とウィルコッ
クス（Ｗｉｌｃｏｘ）の論文“Ｈａｒｄｗａｒｅ　Ａｃ
ｃｅｌｅｒａｔｉｏｎ　ｆｏｒ　Ｗｉｎｄｏｗｓ　Ｓｙ
ｓｔｅｍ”Ｃｏｍｐｕｔｅｒ　　Ｇｒａｐｈｉｃｓ，Ｖ
ｏｌ．２３，Ｎｏ．３，１９８９年７月は、多重ウィン
ドウ処理機を提供するためのハードウェア実施様態を示
している。

【０００５】“Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｉｎ
ｔｅｒｆａｃｅ／Ｖｉｒｔｕａｌ　Ｒｅｓｏｕｒｃｅ　
Ｍａｎａｇｅｒ”，ＩＢＭテクニカル・ディスクロージ
ャ・ブルテン，Ｖｏｌ．３０，Ｎｏ．１，１９８７年６
月は、仮想マシン用のコンテキスト切替機構を開示して
いる。この参照文献では、中央演算処理装置に対する完
全なコンテキストが切り替えられる。

【０００６】“Ｓｃｒｅｅｎ−Ｓｈａｒｉｎｇ　Ｒｉｎ
ｇ　ｆｏｒ　Ｅｎｈａｎｃｅｄ　Ｍｕｌｔｉｐｌｅ　Ａ
ｐｐｌｉｃａｔｉｏｎ　Ｄｉｓｐｌａｙ”，ＩＢＭテク
ニカル・ディスクロージャ・ブルテン，Ｖｏｌ．２８，
Ｎｏ．８，１９８６年１月は、専用の長方形サブエリア
内に表示されるディスプレイ・ウィンドウをレイアウト
するための技法を開示している。

【０００７】“Ａｓｙｎｃｈｒｏｎｏｕｓ　Ｄａｔａ　
Ｔｒａｎｓｆｅｒ　Ｂｕｆｆｅｒ　ｆｏｒ　ＮＰ　Ｓｙ
ｓｔｅｍｓ”，ＩＢＭテクニカル・ディスクロージャ・
ブルテン，　Ｖｏｌ．２５，Ｎｏ．８，１９８３年１月
は、プロセッサが互いに通信して、共通の私用メモリに
アクセスする際に競合が発生しないようにする、多重処
理通信システムを開示している。

【０００８】“Ｈａｒｄｗａｒｅ　Ｄｉｓｐｌａｙ　Ｗ
ｉｎｄｏｗｉｎｇ　Ｓｙｓｔｅｍ”，ＩＢＭテクニカル
・ディスクロージャ・ブルテン，Ｖｏｌ．２８，Ｎｏ．
１２，１９８６年５月は、多重プロセッサによって共用
される表示装置と共に用いるハードウェア・ウィンドウ
処理システムを開示している。

【０００９】“Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ　Ｓｙｓ
ｔｅｍ　ｔｏ　Ｉｍｐｒｏｖｅ　Ｃｏｎｔｅｘｔ　Ｓｗ
ｉｔｃｈｉｎｇ”，ＩＢＭ　テクニカル・ディスクロー
ジャ・ブルテン，Ｖｏｌ．２７，Ｎｏ．５，１９８４年
１０月は、一時に１台のプロセッサだけが活動状態であ
ると指定することによって、コンテキストの切替えを減
らす処理システムを開示している。

【００１０】“Ｍｕｌｔｉ−Ｔａｓｋｉｎｇ　Ｕｓｉｎ
ｇ　Ｃｏ−Ｅｑｕａｌ　Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ
ｓ　Ｈａｖｉｎｇ　Ｍｅｍｏｒｙ−Ｌｏｃｋ　Ｆａｃｉ
ｌｉｔｉｅｓ”，ＩＢＭ　テクニカル・ディスクロージ
ャ・ブルテン，Ｖｏｌ．２４，Ｎｏ．１，１９８１年１
１月は、共通の共用メモリを使用する多重処理システム
用のロック方式を開示している。

【００１１】

【発明が解決しようとする課題】本発明の目的は、第１
および第２のポートを有する周辺装置を少なくとも１つ
含む、複数のプロセスを実行するための、マルチタスク
式データ処理システムを提供することである。

【００１２】

【課題を解決するための手段】ある周辺装置全体を制御
するための周辺装置へのアクセス権を、１つのプロセス
だけに与える能力を含む周辺装置マネジャが提供される
。この周辺マネジャは、第１のプロセスに周辺装置の１
つのポートへのアクセス権を与え、それとは独立にかつ
同時に、第２のプロセスにその周辺装置の第２のポート
へのアクセス権を与える能力をも含んでいる。

【００１３】

【実施例】本発明は、マルチタスク式オペレーティング
・システムで典型的なタイム・シェアリング（同時的）
環境で実行されている複数のアプリケーション・プロセ
スに、ディスプレイ・アクセス権を与えるためのデータ
処理機構に関するものである。図１では、これらのアプ
リケーション・プログラム（ユーザに対するディスプレ
イ出力を必要とするアプリケーション・プログラム）が
、クライアントＡ（１６）、クライアントＢ（１８）お
よびクライアントＣ（２０）として示されている。これ
ら３つのアプリケーション・プログラム１６、１８、２
０は、ユーザにはアプリケーション・プログラムのすべ
てが同時に実行されているように見えるマルチタスク環
境で実行されている命令として、中央演算処理装置１０
内に存在する。さらに、Ｘサーバ１４がある。プログラ
ム・モジュールＸサーバ１４は、ディスプレイ資源マネ
ジャとして、特に、ディスプレイ出力を必要とするアプ
リケーション・プログラムのためにディスプレイの資源
を管理するために、ＵＮＩＸシステム内に設けられてい
る。従来の技術では、クライアントＡ１６などのアプリ
ケーション・プログラムは、Ｘサーバ１４、ポート１２
Ａを介してのみ表示装置１２とインタフェースする。 実際、表示装置へのアクセスを必要とするアプリケーシ
ョン・プログラムはすべて、Ｘサーバを介してのみ、表
示装置とインタフェースするはずである。本発明では、
クライアントＢ１８やクライアントＣ２０などのアプリ
ケーション・プログラムは、表示装置１２に対する直接
ウィンドウ・アクセス（ＤＷＡ）を実行する能力を与え
られている。当初、クライアントＢ１８およびクライア
ントＣ２０は、ディスプレイ上のウィンドウなど、表示
装置資源をそれらに割り振らせるために、Ｘサーバ１４
にアクセスしなければならない。しかし、資源が割り振
られた後には、クライアントＢ１８およびクライアント
Ｃ２０は、ユーザへの情報を表示するために、ポート１
２Ｂを介して表示装置１２に対し直接ウィンドウ・アク
セス機能を実行する。これらのアクセスは、クライアン
トＢ１８およびクライアントＣ２０が互いに独立に存在
できるような形で実行される。

【００１４】また、図１には、描出コンテキスト・マネ
ジャ（ＲＣＭ）２２も含まれている。一般的に言うと、
ＲＣＭ２２は、表示装置にアクセスしているプログラム
（Ｘサーバ１４、クライアントＢ１８またはクライアン
トＣ２０）のそれぞれが、表示装置１２にアクセスして
いる他のプログラムのいずれともインタフェースする必
要なしに、それを行なえるような機構をもたらしている
。表示装置１２は、順次再使用可能な装置として扱わな
ければならない、ＣＲＴディスプレイ用の通常の表示装
置である。言い替えると、表示装置は、一時に１つのア
プリケーション・プログラムのデータだけが見えると期
待する。したがって、ＲＣＭ２２は、いかなる所与の瞬
間にも１つのアプリケーション・プログラム１つに表示
装置１２へのアクセスを許し、同時にそれがＸサーバ１
４、クライアントＢ１８およびクライアントＣ２０から
見えるようにして、これらのアプリケーション・プログ
ラムが、その表示装置に同時にデータを供給できるよう
にする。言い替えれば、Ｘサーバ１４と、他のアプリケ
ーション・プログラム１８および２０は共に、他のどの
装置が表示装置１２にアクセスを試みているかについて
は関心をもたずに、表示装置１２に対して直接読み書き
できる。とはいえ、いかなる時点でも表示装置１２に対
して書込みまたは読取りを行なえるのは、Ｘサーバ、ク
ライアントＢまたはクライアントＣのうちの１つだけで
ある。

【００１５】Ｘサーバ１４に接続されたクライアントＡ
１６は、その情報のすべてを、Ｘサーバ１４を介して表
示装置１２とやり取りする。これは、クライアント−サ
ーバ環境での従来技術の典型的なディスプレイ・アダプ
タ・インタフェースである。しかし、あるクラスのアプ
リケーション・プログラムでは性能要件が増大している
ため、それを満たすために直接ウィンドウ・アクセス能
力が必要である。

【００１６】ＲＣＭ２２は、（ａ）いかなる所与の時点
でも、表示装置１２へのアクセスを望むプロセスのうち
の１つだけが、それを行なえるようにし、かつ（ｂ）そ
のアプリケーション・プログラムが必要とする、表示装
置の描出コンテキストを切り替えることによって、この
インタフェースを提供する。描出コンテキストとは、Ｘ
サーバ１４、クライアントＢ１８またはクライアントＣ
２０などあるプロセスによって表示装置１２上に確立さ
れる、表示装置がそのプロセスのために正しく描出でき
る環境である。描出コンテキストには、たとえば、ウィ
ンドウ・クリッピング情報および、線の色やスタイル（
すなわち、実線か破線か）などの描出属性が含まれる。 言い替えると、アプリケーション・プログラムがユーザ
にデータを表示する際に、そのアプリケーション・プロ
グラムが必要とするディスプレイ環境を提供しなければ
ならない。ところが、この環境は、アプリケーション・
プログラムごとに異なる。ＲＣＭ２２の機能は、各アプ
リケーション・プログラムに表示装置へのアクセスを許
すときに、そのアプリケーション・プログラムに適した
描出コンテキストまたは環境を確実に表示装置に置くこ
とである。

【００１７】今論じている好ましい実施例では、１個の
表示装置１２が、ＲＣＭ２２に接続されている。しかし
、添付の図面を調べれば当業者には明白なように、複数
の表示装置を接続した状態でも機能するように本発明は
設計されている。

【００１８】図２は、ＲＣＭ２２の詳細図である。ＲＣ
Ｍ２２は、アプリケーション・プログラムへのインタフ
ェースを提供する。部分３０は、アプリケーション・コ
ードを表す。アプリケーション・コード３０は、ＲＣＭ
システム・コール３２と直接インタフェースする（図３
および表１参照）。

【００１９】アプリケーション・プログラムは、ＲＣＭ
２２へのシステム・コールを行なう。ＲＣＭは、ＲＣＭ
データ４４を割り振り、修正し、またはその他何らかの
形でそれにアクセスする。また、ＲＣＭシステム・コー
ル機能は、データ域を介して、図に示した他の構成要素
と通信できる。

【００２０】ＲＣＭタイマ・ハンドラ３４は、タイマ割
込みを処理する機能である。ＲＣＭは、オペレーティン
グ・システムに、ＲＣＭタイマ・ハンドラ３４を周期的
に呼び込ませる。ＲＣＭタイマ・ハンドラ３４は、いく
つかの判断基準を用いて、現在表示装置に対するアクセ
ス権を持っているプロセスからそれを取り上げ、別のプ
ロセスにこの表示装置へのアクセス権を与える（言い替
えれば、描出コンテキストの切替えを開始する）ことが
可能か否かを決定することができる。たとえば、タイマ
・ハンドラ３４が呼び込まれたことは、表示装置に対す
るアクセス権を有する第１のプロセスで、指定された時
間が経過したことを示す。第２のプロセスがその装置に
対するアクセス権を要求している場合、タイマ・ハンド
ラは、コンテキスト切替えを開始し、その結果、第１の
プロセスは、装置にアクセスできなくなり、第２のプロ
セスが、表示装置にアクセスできるようになる。

【００２１】ＲＣＭのヘビー・スイッチ・コントローラ
３６は、オペレーティング・システムのカーネル・プロ
セスである。これは、タイマ・ハンドラ３４やグラフィ
ックス障害ハンドラ４０など、割込みレベルで動作する
ＲＣＭ構成要素によって開始される切替えのうち、その
実行に、オペレーティング・システムが割込みハンドラ
の動作に許可するよりも多くの時間または機能を要する
もの（たとえば、割込みハンドラは休眠できない）を制
御する。たとえば、追加のメモリ資源が必要とされ、そ
の結果かなりの時間を消費する仮想アドレス変換タスク
の実行が必要となる場合などが、制御される切替えであ
る。このヘビー・スイッチ・コントローラ３６は、割込
みハンドラがこの追加のタスクを実行する必要なしに、
この機能を実現する。たとえば、ヘビー・スイッチ・コ
ントローラ３６は、他のプロセスの動作と並行してＤＭ
Ａ転送を開始することができる。

【００２２】ＲＣＭの事象ハンドラ３８は、表示装置か
らの割込みのすべてをさばく割込みハンドラである。こ
れは、外部事象が発生した時点を決定し、事前に設定さ
れた条件に従って、待機中のプロセス（たとえば、ヘビ
ー・スイッチ・コントローラや、アプリケーション・プ
ログラム）に警報を発し、または単に情報をＲＣＭデー
タ記憶域４４に記録する。

【００２３】グラフィックス障害ハンドラ４０は、表示
装置へのアクセスに関係するアプリケーション・プログ
ラムの活動によって発生した（ページ不在に類似の）例
外を処理する、ＲＣＭの機能である。表示装置にアクセ
スする許可を得ていないプロセスが表示装置へのアクセ
スを試みたとき、グラフィックス障害ハンドラ４０が呼
び込まれる。グラフィックス障害ハンドラ４０は、所与
の判断基準に基づいて、障害を発生しているプロセスに
、その装置へのアクセス権を与えるべきか否かを決定す
る。こうした判断基準の例は、現在装置へのアクセス権
を持っているプロセス用のタイマの状態、いずれかのプ
ロセスが装置をロックしているか否か、あるいは変更を
抑止するその他の条件である。そのプロセスに表示装置
へのアクセス権を与えるべきである場合、グラフィック
ス障害ハンドラ４０は、コンテキスト切替えを開始して
、装置上で障害を発生しているプロセスに対する正しい
環境を提供し、以前のプロセスを装置にアクセスできな
くした後に、障害を発生しているプロセスが装置にアク
セスできるようにする。

【００２４】エグジット・ハンドラ４２は、ある種のプ
ロセス状態の変化を処理する機能である。言い替えれば
、プロセスがエグジット（脱出）または終了しようとし
ている（すなわち、もはや表示装置へのアクセスを必要
とせず、さらにＣＰＵさえも必要としない）場合、エグ
ジット・ハンドラ４２は、ＲＣＭデータ記憶域４４内の
データを適当な状態にするために必要な動作を行なう。

【００２５】図３は、描出コンテキスト・マネジャのシ
ステム・コール３２を示す流れ図である。ステップ７０
０で、描出コンテキスト・マネジャは、（汎用レジスタ
およびスタックをセーブするなど）ユーザ・モード環境
をセーブした後に、（カーネル・モード・スタックを用
意するなど）カーネル環境を確立する。このシステム・
コールは、そのシステム・コールが対象とする装置を指
定するパラメータ、実行すべき機能、およびその機能に
必要なパラメータを含んでいる。これらの機能を実行し
た後、ユーザ・モード環境を復元するステップ７０２が
実行される。図３の機能には、機能ＭＡＫＥ＿ＧＰ（グ
ラフィックス・プロセス生成）モジュール７０４が含ま
れる。機能ＭＡＫＥ＿ＧＰは図５に示されている。機能
ＵＮＭＡＫＥ＿ＧＰ（グラフィックス・プロセス削除）
モジュールは図６に示されている。図７は、ＣＲＥＡＴ
Ｅ＿ＲＣＸ（描出コンテキスト作成）モジュール１５０
である。図８は、ＤＥＬＥＴＥ＿ＲＣＸ（描出コンテキ
スト削除）モジュール７１０である。図９は、ＢＩＮＤ
（バインド）モジュール７１２である。図１０は、ＳＥ
Ｔ＿ＲＣＸ（描出コンテキスト設定）モジュール７１４
である。図１１は、ＣＲＥＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴ
ＴＲ（サーバ属性作成）モジュール７１６である。図１
２は、ＤＥＬＥＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲ（サーバ
属性削除）モジュール７１８である。図１３は、ＵＰＤ
ＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲ（サーバ属性更新）モ
ジュール７２０である。図１４は、ＣＲＥＡＴＥ＿ＣＬ
ＩＥＮＴ＿ＡＴＴＲ（クライアント属性作成）モジュー
ル７２２である。図１５は、ＤＥＬＥＴＥ＿ＣＬＩＥＮ
Ｔ＿ＡＴＴＲ（クライアント属性削除）モジュール７２
４である。図１６は、ＵＰＤＡＴＥ＿ＣＬＩＥＮＴ＿Ａ
ＴＴＲ（クライアント属性更新）モジュール７２６であ
る。図１７は、ＬＯＣＫ＿ＤＥＶＩＣＥ（装置ロック）
モジュール７２８である。図１８は、ＵＮＬＯＣＫ＿Ｄ
ＥＶＩＣＥ（装置ロック解除）モジュール７３０である
。図１９は、ＬＯＣＫ＿ＤＯＭＡＩＮ（ドメイン・ロッ
ク）モジュール７３２である。図２０は、ＵＮＬＯＣＫ
＿ＤＯＭＡＩＮ（ドメイン・ロック解除）モジュール７
３４である。これらの機能のそれぞれについて、後で詳
細に説明する。

【００２６】表１は、特にグラフィックス・システム用
のシステム・コール・インタフェースを示す表である。 当業者なら理解する通り、システム・コールは、使用中
のオペレーティング・システムの提供するプロトコルで
ある。本発明では、グラフィックス・システム・コール
は、ＡＩＸオペレーティング・システムで実施されてい
る。

【００２７】 表１ ＧＲＡＰＨＩＣＳ＿ＳＹＳＴＥＭ＿ＣＡＬＬ（Ｄｅｖｉ
ｃｅ，　Ｃｏｍｍａｎｄ，　Ｄａｔａ）Ｄｅｖｉｃｅ＝
特定の表示装置を示す Ｃｏｍｍａｎｄ＝実行すべき特定の機能（たとえば、Ｍ
ＡＫＥ＿ＧＰ、ＣＲＥＡＴＥ＿ＲＣＸなど。）Ｄａｔａ
＝機能特有のデータ構造 （たとえば、ＣＲＥＡＴＥ＿ＲＣＸの場合、この構造は
、以下のフィールドを有する。）エラー・コード、装置
上のドメイン番号、装置特有のデータ構造を指すポイン
タ、装置特有のデータ構造の長さ、作成される抽出コン
テキストの識別子（後続のＧＲＡＰＨＩＣＳ＿ＳＹＳＴ
ＥＭ＿ＣＡＬＬの呼出しで、ＲＣＸを参照するのに用い
る）

【００２８】図４は、ＲＣＭデータ記憶域４４を示す図
である。ＲＣＭ　　共通ブロック５０は、ＲＣＭデータ
記憶域４４に格納されたＲＣＭデータ構造の中心点であ
る。ＲＣＭ共通ブロック５０は、共通プロセス・ブロッ
ク（５２や５４など）のリンク・リストの先頭と、装置
ブロック（５６や５８など）のリンク・リストの先頭を
含む。オペレーティング・システムは、ハンドラがＲＣ
Ｍデータ構造へのアクセス権を得るための手段を提供す
る。

【００２９】共通プロセス・ブロック５２および５４は
、あるプロセスがそれに対するアクセスを必要としてい
るすべての装置に対して大域的な（すなわち、すべての
装置に同一のデータが適用される）情報を含む。これら
のブロックは、各々次の共通プロセス・データ構造（共
通プロセス・データ構造５４など）へのリンク、プロセ
スがアクセスを許可されている装置を示すための装置に
対する許可情報の要約、およびその共通プロセス・デー
タ構造用の装置プロセス・データ構造の数を含む。 共通プロセス・データ構造５２および５４の各部分は、
使用中の特定のオペレーティング・システムによって変
わることを理解されたい。

【００３０】装置データ構造（５６、５８）は、ブロッ
ク６０により詳細に示されている。これは、ＲＣＭ２２
によって管理される表示装置１２の記述である。各装置
構造ブロックは、次の装置構造ブロックへのリンク、設
置プロセス・データ構造（装置プロセス・ブロック６２
や６４など）のリンク・リストの先頭、サーバ・ウィン
ドウ属性データ構造（ブロック６６や６８など）のリン
ク・リストの先頭、その装置がロックされたアプリケー
ション・プロセスを表す装置プロセス・データ構造への
リンク、装置をロックするために待機中のグラフィック
ス・プロセスのリストの先頭、装置専用記憶域へのリン
ク、ドメイン構造のアレイ、および様々な状態を表すフ
ラグを含む。装置データ構造６０には、ドメイン・アレ
イ７０が含まれることに留意されたい。ＲＣＭ２２は、
表示装置の独立なドメインへのアクセスを、独立に許可
できることを理解されたい。装置ドメインとは、グラフ
ィックス・プロセスがデータを供給している先の装置内
の環境である。

【００３１】ドメイン・アレイ７０の各エントリは、そ
のドメインがロックされたアプリケーション・プロセス
を表す装置プロセス・データ構造へのリンク、そのドメ
インをガードまたはロックするために待機中である装置
プロセスのリストの先頭、グラフィックス障害ハンドラ
４０が使用する装置へ戻るリンク、ドメイン許可情報（
すなわち、そのドメインに対するアクセスを、あるプロ
セスに許可するために何を行なうべきかを示す情報）、
そのドメイン用の現在の描出コンテキスト（すなわち、
現在そのドメインにロードされている描出コンテキスト
）へのリンク、現在の描出コンテキストを所有するプロ
セスを表す装置プロセス・データ構造へのリンク、障害
リスト（そのドメインへのアクセスを試みて障害を発生
したグラフィックス・プロセス用の描出コンテキストの
リンク・リスト）の先頭、タイマ情報、およびその他の
関連する状態を表す様々なフラグを含む。

【００３２】装置プロセス・データ構造７２（６２）は
、グラフィックス・プロセスが特定の表示装置にアクセ
スするのに必要な情報を含む。たとえば、装置プロセス
・データ構造は、次の装置プロセス・データ構造へのリ
ンク、装置プロセス・データ構造（共通プロセス・デー
タ構造５２など）へのリンク、その表示装置上でのグラ
フィックス・プロセスの優先順位、グラフィックス・プ
ロセスが生成した描出コンテキスト・データ構造（描出
コンテキスト・データ構造７４および７６など）のリン
ク・リストの先頭、クライアント・ウィンドウ属性デー
タ構造（クライアント・ウィンドウ属性ブロック７８お
よび８０など）へのリンク・リストの先頭、装置専用記
憶域へのリンク、様々な状態を表すフラグ、およびグラ
フィックス・プロセス用の装置の各ドメインに対する現
在の描出コンテキストへのリンクのアレイが含まれる。

【００３３】描出コンテキスト・ブロック（ブロック７
４など）は、描出コンテキストを定義する情報をすべて
含む。たとえば、描出コンテキスト・ブロックは、次の
描出コンテキストへのリンク、障害リスト内の次の描出
コンテキストへのリンク、その描出コンテキストを作成
したグラフィックス・プロセス用の装置プロセス・デー
タ構造へのリンク、その描出コンテキストの現在の優先
順位、それに対してその描出コンテキストが作成された
ドメインへのリンク、その描出コンテキストにバインド
されたサーバ・ウィンドウ属性データ構造へのリンク、
その描出コンテキスト・ブロックにバインドされたクラ
イアント・ウィンドウ属性データ構造へのリンク、装置
専用記憶域へのリンク、様々な状態を表すフラグ、サー
バ・ウィンドウ属性データ構造にバインドされた描出コ
ンテキストのリスト中の次の描出コンテキストへのリン
ク、クライアント・ウィンドウ属性データ構造にバイン
ドされた描出コンテキストへのリスト中の描出コンテキ
ストへのリンクを含む。

【００３４】サーバ・ウィンドウ属性データ構造（ブロ
ック６６および６８など）は、サーバから割当てを受け
なければならないウィンドウ・ジオメトリ（たとえば、
形状と位置）の記述を含む。各サーバ・ウィンドウ属性
データ構造は、次のサーバ・ウィンドウ属性データ構造
へのリンク、このサーバ・ウィンドウ属性データ構造に
バインドされた描出コンテキスト・データ構造のリンク
・リストの先頭、このサーバ・ウィンドウ属性データ構
造を作成したグラフィックス・プロセス用の装置プロセ
ス・データ構造へのリンク、ウィンドウ・ジオメトリお
よびカラー・マップの記述、装置専用記憶域へのリンク
、および様々な状態を表すフラグを含む。

【００３５】クライアント・ウィンドウ属性データ構造
（ブロック７８および８０など）は、ウィンドウ用の資
源の記述を含み、クライアントによって割り当てられる
。具体的には、これらのデータ構造は、次のクライアン
ト・ウィンドウ属性データ構造へのリンク、このクライ
アント・ウィンドウ属性データ構造にバインドされた描
出コンテキスト・データ構造のリンク・リストの先頭、
クライアント・クリップ・ジオメトリの記述、そのウィ
ンドウでの画素の解釈（たとえば、その画素がカラー・
ディレクトリとして使用されるのか、ルックアップ・テ
ーブルへの指標として使用されるのか）の記述、装置専
用記憶域へのリンク、様々な状態を表すフラグを含む。

【００３６】図４に示したデータ構造は、複数のプロセ
スまたは複数の装置に共通するデータには１個の記憶域
を提供し、必要なときはデータを別々のデータ構造に分
離することにより、データ記憶空間を節約する点で有利
である。この結果、データを検索する際の検索時間が節
約され、ＲＣＭ機能を実施するのに必要なデータの量が
最小になる。

【００３７】図５ないし図３０は、描出コンテキスト・
マネジャ２２の動作を流れ図の形で詳細に記述している
。図を単純にするため、エラー状態は含まれていない。 ＲＣＭ２２を制御するために用いるシステム・コールは
、複数の機能のうちの１つを要求することができる。図
５ないし図２０は、これらの異なる機能を示す。 図５で、ＭＡＫＥ＿ＧＰ（グラフィックス・プロセス作
成モジュール）１００は、あるプロセスをグラフィック
ス・プロセスにする。それには、ディスプレイ・アダプ
タへのアクセスを許可し、その表示装置にアクセスする
プロセスが使用する表示装置アドレスを返す。また、こ
の機能は、ＲＣＭ２２を始めて呼び出したとき初期設定
する。ＭＡＫＥ＿ＧＰ１００は、グラフィックス・プロ
セスの作成に必要な、装置特有の機能を実行できる、装
置特有のＭＡＫＥ＿ＧＰ（）１０８を呼び出す。装置特
有のＭＡＫＥ＿ＧＰ（）１０８は、システム内で表示装
置をサポートするのに必要な装置ドライバ・ソフトウェ
アの一部である。この装置ドライバ・ソフトウェアには
、描出制御管理の装置特有の様態をサポートする他の機
能も含まれている。呼出し側プロセスが、ＭＡＫＥ＿Ｇ
Ｐ１００およびその他すべてのＲＣＭ２２システム・コ
ール機能に渡さなければならないパラメータの１つは、
装置識別子である。この識別子は、ＲＣＭに、呼出し側
プロセスが、複数の装置のうちのどの装置に対するグラ
フィックス・プロセスになりたいのかを理解させる。こ
の装置識別子は、すべてのＲＣＭシステム・コール機能
用のパラメータである。ＭＡＫＥ＿ＧＰ１００用のもう
１つのパラメータは、ＭＡＫＥ＿ＧＰがＭＡＫＥ＿ＧＰ
（）１０８に渡す、呼出し側プロセスからの情報である
。ＭＡＫＥ＿ＧＰ１００は、表示装置の各ドメイン用に
、空描出コンテキストを作成する。空描出コンテキスト
は、プロセスを装置にアクセスさせるが、このプロセス
による活動を可視的なものにはしない。これは主に、プ
ロセス初期設定状況およびプロセス出口状況で用いられ
る。次に、ＭＡＫＥ＿ＧＰ１００は、装置特有のＲＣＸ
（）１１１を呼び出す。装置特有のＲＣＸ（）１１１は
、新しいコンテキストを作成するのに必要な、装置特有
の機能を実行する。

【００３８】ＭＡＫＥ＿ＧＰモジュールは、ステップ１
０１から始まる。ステップ１０１で、描出コンテキスト
・マネジャが、呼び出されているプロセス用の共通デー
タ構造がすでに存在しているか否かを決定する。存在し
ない場合は、ステップ１０２に進んで、記憶域を割り振
り、メモリをピン付け（データ構造が実記憶域内に留ま
って、通常はディスクである補助記憶装置に「ページ・
アウト」されないようにすること）し、データ構造を初
期設定し、障害ハンドラおよびエグジット・ハンドラを
オペレーティング・システム・カーネルで登録して、適
当な状況の下で、それらがカーネルから呼び出されるよ
うにして、共通データ構造を構築する。また、ヘビー・
スイッチ・コントローラを、カーネル・プロセスとして
起動する。ステップ１０３で、ＲＣＭが、装置データ構
造が存在するか否かを決定する。存在しない場合は、や
はりステップ１０４で、装置データ構造およびドメイン
・データ構造の双方のために、メモリを割り振り、ピン
付けし、初期設定する。また、ＲＣＭは、各ドメイン用
のタイマをセットアップし、タイマ・ハンドラをカーネ
ルで登録する。最後に、ＲＣＭは、装置データ構造を共
通データ構造にリンクする。ステップ１０５で、呼出し
側のプロセス用の共通プロセス・データ構造が存在する
か否かを決定する。存在しない場合は、ステップ１０６
で、共通プロセス・データ構造を作成し、ピン付けし、
初期設定する。ステップ１０７で、装置プロセス・デー
タ構造を形成する。ステップ１０８で、装置特有のモジ
ュールＭＡＫＥ＿ＧＰを呼び出して、装置のアドレッシ
ング情報を得る。装置特有のモジュールＭＡＫＥ＿ＧＰ
は、特定の装置用の装置ドライバの一部である。ステッ
プ１０９で、すべての装置ドメインについて、空描出コ
ンテキストが存在するか否かを決定する。存在しない場
合は、ステップ１１０と１１１を含むループに進んで、
装置特有の必要な初期設定を行なうために、装置特有の
ＣＲＥＡＴＥ＿ＲＣＸ（）を呼び出して、空描出コンテ
キスト・データ構造を作成し、初期設定する。空描出コ
ンテキストデータ構造がすべてセットアップされると、
ステップ１１２に進んで、装置プロセス・データ構造を
装置構造にリンクし、共通プロセス・データ構造内のカ
ウンタを１つ増分する。ステップ１１３で、装置アドレ
ス情報が返される。

【００３９】図６のＵＮＭＡＫＥ＿ＧＰ（グラフィック
ス・プロセス解除）ルーチンは、図５のルーチンＭＡＫ
Ｅ＿ＧＰの反対である。本質的に、ルーチンＵＮＭＡＫ
Ｅ＿ＧＰの目的は、ＲＣＭがあるプロセスをグラフィッ
クス・プロセスとして扱えるようにするデータ構造をア
ンドゥーすることである。ステップ１１９で、装置が呼
出し側プロセスによってロックされている場合、それが
ロック解除される。これには、その装置がロック解除さ
れるのを待機している他のプロセスをすべて覚醒させる
ことが含まれる。ステップ１２１および１２２で、ＲＣ
Ｍは、呼出し側プロセスによってロックされたすべての
ドメインがロック解除されたことを確認するループに入
る。ステップ１２３および１２４で、ＲＣＭは、そのプ
ロセスの所有する描出コンテキストがすべて削除された
ことを確認するもう１つのループに入る（図８参照）。 ステップ１２５、１２６および１２７で、ＲＣＭは、そ
のプロセスが作成したサーバ属性がすべて削除されたこ
とを確認する（図１２参照）。サーバ属性データ構造が
すべて削除された後、ステップ１２８および１２９に進
み、呼出し側プロセスによって作成されたクライアント
属性データ構造がすべて削除されたことを確認する。ス
テップ１３０で、装置特有のルーチンＵＮＭＡＫＥ＿Ｇ
Ｐ（）が呼び出される。これは、その装置特有の装置ド
ライバ・ルーチンであり、ＭＡＫＥ＿ＧＰ（）など装置
特有の機能によってそのプロセス用に作成された、装置
特有のデータ構造を削除する。ステップ１３１で、装置
プロセス・データ構造が装置からリンク解除され、以前
に割り振られたメモリが解放される。次に、共通プロセ
ス・データ構造のカウントを１つ減分する。ステップ１
３２で、これがその装置を使用している最後のプロセス
であったか否かを決定する。そうである場合は、ＲＣＭ
はもはやその装置を管理する必要がなく、装置データ構
造が共通データ構造からリンク解除され、ドメイン・タ
イマが解放され、装置データ構造用のメモリが解放され
る。ステップ１３４で、これが呼出し側プロセスの使用
する最後の装置であるか否かを決定する。そうである場
合は、このプロセスはもはや表示装置上のグラフィック
ス・プロセスである必要はなく、ＲＣＭは、共通データ
構造から共通プロセス・データ構造をリンク解除し、そ
のプロセスのアドレス空間から入出力バスを取り上げ、
共通プロセス・データ構造用のメモリを解放する。ステ
ップ１３６で、最後の共通プロセス・データ構造が削除
されたか否かを決定する。そうである場合は、ＲＣＭは
それ自体を停止させることができ、ステップ１３７で、
障害ハンドラの登録を解除し、エグジット・ハンドラの
登録を解除し、ヘビー・スイッチ・コントローラを終了
させ、ＲＣＭが使用する残りのメモリ（たとえば、共通
データ構造）をすべて解放する。

【００４０】図７では、描出コンテキストの作成が実行
される。装置パラメータとドメイン・パラメータが、こ
のコンテキスト構造を作成する際に使用され、作成され
る描出コンテキスト・データ構造は、ある装置とその装
置のドメインに特有のものである。ステップ１５１で、
メモリが割り振られ、ピン付け（実記憶域内に保持）さ
れ、コンテキスト・データ構造が初期設定される。ステ
ップ１５２で、装置特有のコンテキスト作成モジュール
（装置ドライバの一部）が呼び出される。システム・コ
ールで渡されたデータが、装置特有のＣＲＥＡＴＥ＿Ｒ
ＣＸ（）に渡される。これによって、呼出し側プロセス
は、装置特有の、描出コンテキスト・データ構造に関連
するデータをカスタマイズする際に使用できる情報を、
装置特有のＣＲＥＡＴＥ＿ＲＣＸ（）に渡せるようにな
る。ステップ１５３で、コンテキスト・データ構造が、
装置プロセス・データ構造にリンクされる。ステップ１
５４で、ＲＣＭがハンドルを返す。後続のＲＣＭシステ
ム・コール（たとえば、ＢＩＮＤまたはＳＥＴ＿ＲＣＸ
など）の際に、呼出し側プロセスは、このハンドルを用
いてこのコンテキストを識別できる。

【００４１】図８では、コンテキストの削除が実行され
る。ステップ１６２で、削除すべきコンテキストが、そ
のコンテキストのドメインに関して、呼出し側プロセス
の現在のコンテキストであるか否かを決定する。そうで
ある場合は、ステップ１６３で、空コンテキストをその
ドメインに対する現在のコンテキストにする。これは、
将来その呼出し側プロセスがそのドメインにアクセスし
ようと試みた場合に対する安全装置である。ステップ１
６４で、ＧＵＡＲＤ＿ＤＯＭＡＩＮ（ドメイン・ガード
）ルーチンが呼び出される。この内部機能は、ガード解
除されるまで、そのドメイン上でコンテキスト切替えが
起こらないようにする。これが必要なのは、表示装置の
性質上、ある装置特有の機能がコンテキスト切替えを実
行することが必要となることがあり得るためである。 ドメインをガードすることで、装置特有の機能が、ＲＣ
Ｍのハンドラ構成要素から妨害（たとえば、ドメインの
コンテキストを切り替えようと試みることなど）を受け
ないことが保証される。ステップ１６５で、装置特有の
削除ルーチン（装置ドライバの一部）を呼び出して、装
置特有の機能をすべて実行し、描出コンテキスト・デー
タ構造に関連する装置特有のデータ構造を削除する。次
に、ドメインをガード解除する。ステップ１６６で、そ
のドメインの現在のコンテキストが削除されつつあるか
否かを決定する。そうである場合は、ステップ１６７で
、プロセスがそのドメインにアクセスする許可を取り除
き、このドメインに対するコンテキストが存在しないこ
とを指示する。これによって、次にコンテキスト切替え
が必要になったとき、古いコンテキストをセーブする必
要がないので、より簡単に切替えが行なえるようになる
。ステップ１６８で、コンテキスト・データ構造を、サ
ーバ属性データ構造およびクライアント属性データ構造
からリンク解除する。ステップ１６９で、描出コンテキ
ストのメモリが解放される。

【００４２】図９は、描出コンテキスト・データ構造、
サーバ・ウィンドウ属性データ構造およびクライアント
・ウィンドウ属性データ構造を関連付ける役割を持つＢ
ＩＮＤ（バインド）モジュールを示す。この３つ組は、
表示装置のドメインが、呼び出されたプロセスに正しく
描出させるために必要な環境を定義する。呼出し側プロ
セスは、これら３つのデータ構造を識別するハンドルを
与える。ステップ１８１で、そのドメインをガードし、
その間にステップ１８２で、装置特有のＢＩＮＤモジュ
ールが呼び出される。装置特有のＢＩＮＤモジュールは
、特定の装置用の装置ドライバの一部である。ステップ
１８３で、ドメインをガード解除する。ステップ１８４
で、描出コンテキスト・データ構造を古いサーバ属性デ
ータ構造からリンク解除して、新しいサーバ属性データ
構造にリンクする。次に、新しいサーバ属性データ構造
を、描出コンテキスト・データ構造にリンクする。ステ
ップ１８５で、この描出コンテキストを、古いクライア
ント属性データ構造からリンク解除して、新しいクライ
アント属性データ構造にリンクすると同時に、新しいク
ライアント属性データ構造も描出済みコンテキスト・デ
ータ構造にリンクする。これらのリンクはすべて、様々
なデータ構造の間の関連を記録するために必要である。 これらのリンクにより、描出コンテキストと、それにバ
インドされた属性データ構造の検索時間が最小になる。 アプリケーションにとって好都合ならば、これらのリン
クによって、多くの描出コンテキストを同一の属性デー
タ構造にバインドすることができる。たとえば、資源サ
ーバがサーバ・ウィンドウ属性を作成する際に、一般に
、描出コンテキストをそれにバインドして、たとえばウ
ィンドウの背景をクリアして、なんらかのユーザ指定の
色またはパターンまたはその両方にできるようにする。 ただし、その後、直接ウィンドウ・アクセス・クライア
ントが、その（同一のサーバ・ウィンドウ属性によって
指定される）ウィンドウに自分の異なる描出コンテキス
ト・データ構造をバインドして、そのウィンドウを使っ
て、線や陰影付きの表面などを描画することもできる。

【００４３】図１０は、ＳＥＴ＿ＲＣＸ（描出コンテキ
スト設定）モジュールの流れ図である。このモジュール
は、プロセスがあるドメインに対する現在の３つ組（描
出コンテキスト、サーバ・ウィンドウ属性およびクライ
アント・ウィンドウ属性）を指定できるようにする。ス
テップ２０１で、ＲＣＭは、その描出コンテキストを装
置プロセス・データ構造内のそのドメイン用の現在のコ
ンテキストとしてセットする。ステップ２０２で、その
ドメインが現在のプロセスによって使用されているか、
またはどのプロセスにも使用されていないか否かを決定
する。それがこのプロセスによって使用されているか、
またはどのプロセスにも使用されていない場合は、ステ
ップ２０３で、ＲＣＭは、ドメイン・タイマをキャンセ
ルし、ステップ２０４で、ドメインをガードし、次にス
テップ２０５で、新しい描出コンテキストに切り替え、
最後にステップ２０６で、ドメインをガード解除する。

【００４４】図１１に、ＣＲＥＡＴＥ＿ＳＥＲＶＥＲ＿
ＡＴＴＲ（サーバ属性作成）モジュールの流れ図を示す
。ステップ２２１で、データ構造を割り振り、サーバ属
性データ構造を初期設定する。ステップ２２２で、ウィ
ンドウ・ジオメトリ（すなわち、ウィンドウの位置およ
び形状の記述）を呼出し側からコピーする。このジオメ
トリ情報は、呼出しと一緒に渡さなければならない情報
である。ステップ２２３で、サーバ・ウィンドウ属性デ
ータ構造を作成するのに必要な、装置特有の活動を実行
する、装置特有のＣＲＥＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴ
Ｒモジュールを呼び出す。これは、使用中の装置特有の
装置ドライバ・モジュールである。ステップ２２４で、
サーバ属性データ構造を装置データ構造にリンクする。 ステップ２２５で、サーバ・ウィンドウ属性のハンドル
を返す。

【００４５】図１２は、ＤＥＬＥＴＥ＿ＳＥＲＶＥＲ＿
ＡＴＴＲ（サーバ属性削除）モジュールの流れ図である
。ＤＥＬＥＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲモジュールは
、単にＣＲＥＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲモジュー
ルが行なったことをアンドゥーするだけである。ステッ
プ２４２で、ＲＣＭは、サーバ・ウィンドウ属性データ
構造がバインドされているすべての描出コンテキストが
更新されて、サーバ・ウィンドウ属性の削除を反映する
（描出コンテキストがもはや、そのコンテキストを所有
しているプロセスの活動を可視的にできない）ようにな
ったことを確認するループに入る。ステップ２４２で、
ＲＣＭは、このサーバ・ウィンドウ属性データ構造にバ
インドされている描出済みコンテキストがすべて更新済
みであるか否かを決定する。そうでない場合は、ステッ
プ２４３で、ドメインをガードし、ステップ２４４で、
装置特有のＤＥＬＥＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲモジ
ュールを呼び出す。これは、やはり装置ドライバの一部
である。このモジュールは、ウィンドウ処理情報を変更
するために、その装置に対する適当なアクセスを可能に
するための、コンテキスト切替えを含めて、装置からサ
ーバ属性を削除するのに必要な装置特有の活動を実行し
、そのサーバ・ウィンドウ属性をサポートするために作
成されたデータ構造を削除する。ステップ２４５で、ド
メインをガード解除し、ステップ２４６で、サーバ属性
データ構造を描出コンテキスト・データ構造からリンク
解除する。このループから出ると、ＲＣＭはステップ２
４７に進んで、サーバ属性データ構造を装置データ構造
からリンク解除し、サーバ属性データ構造を解放する。

【００４６】図１３は、ＵＰＤＡＴＥ＿ＳＥＲＶＥＲ＿
ＡＴＴＲ（サーバ属性更新）モジュールを示す流れ図で
ある。プロセスは、ウィンドウの位置または形状、ある
いはその両方を変更するために、このＲＣＭ機能を呼び
出す。ステップ２６１で、システム・コールのパラメー
タを介して、呼出し側から新しいウィンドウ・ジオメト
リを受け取る。ステップ２６２で、ＲＣＭは、そのサー
バ・ウィンドウ属性にバインドされた描出コンテキスト
のすべてに対するサーバ・ウィンドウ属性が更新される
ようにする、ステップ２６３、２６４、２６５からなる
ループに入る。ステップ２６３で、ドメインをガードし
、ステップ２６４で、装置ドライバ特有のＵＰＤＡＴＥ
＿ＳＥＲＶＥＲ＿ＡＴＴＲモジュールを呼び出して、装
置特有のデータ構造を更新し、新旧両方のウィンドウ・
ジオメトリ情報を渡す。その後に、ドメインをガード解
除する。描出コンテキストがすべて更新されると、ステ
ップ２６６に進んで、サーバ属性データ構造を更新する
。

【００４７】図１４は、クライアント属性データ構造を
対象としている点を除いて、図１１と同じである。ステ
ップ２８１で、ＲＣＭは、メモリを割り振り、クライア
ント属性データ構造を初期設定する。ステップ２８２で
、ＲＣＭは、呼出し側からのクライアント・クリップ情
報と画素解釈をコピーする。クライアント・クリップ情
報は、（サーバ・ウィンドウ属性によって記述されるウ
ィンドウ・クリッピングに加えて）プロセスによって装
置に送られた描出コマンドの追加のクリッピングを行な
うために使用される。ステップ２８３で、クライアント
・ウィンドウ属性データ構造を作成するのに必要な装置
特有の活動を実行する、装置特有のＣＲＥＡＴＥ＿ＣＬ
ＩＥＮＴ＿ＡＴＴＲモジュールを呼び出す。これは、使
用中の装置特有の装置ドライバ・モジュールである。 ステップ２８４で、クライアント属性データ構造を装置
プロセス・データ構造にリンクし、次にステップ２８５
で、クライアント属性ハンドルを返す。

【００４８】図１５は、ＤＥＬＥＴＥ＿ＣＬＩＥＮＴ＿
ＡＴＴＲ（クライアント属性削除）モジュールを対象と
している点を除いて、図１２に類似している。ステップ
３０２で、クライアント・ウィンドウ属性にバインドさ
れた描出コンテキストがすべて処理済みであるか否か決
定する。そうでない場合は、ＲＣＭは、ステップ３０３
、３０４、３０５、３０６からなるループに入る。ステ
ップ３０３で、ドメインをガードする。ステップ３０４
で、装置特有のＤＥＬＥＴＥ＿ＣＬＩＥＮＴ＿ＡＴＴＲ
モジュールを呼び出す。これは、アドレスされている表
示装置特有の装置ドライバである。このモジュールは、
クリッピング情報を変更するためにその装置に対する適
当なアクセスを可能にするなんらかのコンテキスト切替
えを含めて、装置からクライアント・ウィンドウ属性を
削除するのに必要な装置特有の活動を実行し、そのクラ
イアント・ウィンドウ属性をサポートするために作成さ
れたデータ構造を削除する。ステップ３０５で、ドメイ
ンをガード解除する。ステップ３０６で、クライアント
属性データ構造を描出コンテキスト・データ構造からリ
ンク解除する。ステップ３０６の後、ＲＣＭはステップ
３０２に戻る。描出コンテキストがすべて処理済みにな
るまでこのループを、繰り返す。その後、ＲＣＭはステ
ップ３０７に進んで、クライアント属性データ構造を装
置プロセス・データ構造からリンク解除し、クライアン
ト属性データ構造を解放する。

【００４９】図１６は図１３に類似している。図１６は
、ＵＰＤＡＴＥ＿ＣＬＩＥＮＴ＿ＡＴＴＲ（クライアン
ト属性更新）モジュールである。プロセスは、そのクラ
イアント・クリップまたは画素解釈の要件を更新するた
めにこの機能を呼び出す。ステップ３２１で、呼出し側
からＲＣＭは新しいクライアント・クリップ情報をコピ
ーする。次にＲＣＭハ、クライアント・ウィンドウ属性
にバインドされた描出コンテキストのすべてに対するク
ライアント・ウィンドウ属性が更新されるようにするた
め、ステップ３２２、３２３、３２４、３２５からなる
ループに入る。ステップ３２２で、ＲＣＭは、描出済み
コンテキストのすべてが処理済みであるか否かを決定す
る。そうでない場合、ステップ３２３で、ドメインをガ
ードする。ステップ３２４で、装置特有のＵＰＤＡＴＥ
＿ＣＬＩＥＮＴ＿ＡＴＴＲモジュールを呼び出して、装
置特有のデータ構造を更新し、新旧両方のクライアント
・クリップなどの記述を渡す。これは、装置特有のドラ
イバ・モジュールである。ステップ３２５で、ドメイン
をガード解除する。描出コンテキストの処理が完了する
と、ＲＣＭはステップ３２６に進んで、クライアント属
性データ構造を更新する。

【００５０】図１７は、ＬＯＣＫ＿ＤＥＶＩＣＥ（装置
ロック）モジュールの流れ図である。ＬＯＣＫ＿ＤＥＶ
ＩＣＥモジュールの目的は、資源サーバ・プロセスが、
割込みなしに装置にアクセスできるようにすることであ
る。これは、ウィンドウの位置変更など重要事象中に必
要である。ステップ３４１で、ＲＣＭは、装置がロック
されているか否かを決定する。そうでない場合は、ＲＣ
Ｍはステップ３４５に進む。そうである場合は、ＲＣＭ
は、ステップ３４２に進み、装置が呼出し側によってロ
ックされているか否かを決定する。そうである場合は、
ＲＣＭはこのルーチンから出る。そうでない場合は、ス
ッテップ３４３に進んで、そのプロセスが、装置がロッ
ク解除されるまで待機した後にその装置をロックするこ
とを望んでいるか否かを決定する。そうでない場合は、
ＲＣＭはこのルーチンから出る。プロセスが待機を望ん
でいる場合は、ＲＣＭはステップ３４４に進んで、現在
装置をロックしているプロセスが、その装置をロック解
除するまで、休眠（待機）する。このプロセスが覚醒す
ると（図１８参照）、ＲＣＭはステップ３４５に進む。 ステップ３４５で、その装置が呼出し側プロセスに対し
てロックされる。次にＲＣＭは、ステップ３４６および
３４７からなる、すべての装置ドメインがロックされる
ループに入る。これは、ステップ３４７で、ドメインを
ガードではなくロックするようにと指示するパラメータ
を与えて、ＧＵＡＲＤ＿ＤＯＭＡＩＮ機能を実行するこ
とによって行なわれる。すべてのドメインがロックされ
ると、ステップ３４６で、ＲＣＭはこのルーチンから出
る。

【００５１】図１８は、ＬＯＣＫ＿ＤＥＶＩＣＥモジュ
ールが図１７で行なったことを効果的にアンドゥーする
、ＵＮＬＯＣＫ＿ＤＥＶＩＣＥ（装置ロック解除）モジ
ュールの流れ図を示す。ステップ３６１で、ＤＥＶＩＣ
Ｅ　　ＬＯＣＫＥＤ（装置ロック済み）フラグがクリア
される。ステップ３６２で、装置がロック解除されるま
で休眠（待機）していたプロセスを、覚醒させる（活動
化する）。次にＲＣＭは、ステップ３６３および３６４
からなる、装置上のすべてのドメインをガード解除する
ループに入る。これが完了すると、ＲＣＭはこのルーチ
ンから出る。

【００５２】図１９は、ＬＯＣＫ＿ＤＯＭＡＩＮ（ドメ
イン・ロック）モジュールの流れ図を示す。ステップ３
８１で、ＲＣＭは、ドメインがロックされているか否か
を決定する。そうでない場合は、ＲＣＭはステップ３８
５に進む。そうである場合は、ＲＣＭはステップ３８２
に進んで、ドメインがすでに呼出し側によってロックさ
れているか否かを決定する。そうである場合は、ＲＣＭ
は続行する理由がないので、ルーチンから出る。そうで
ない場合は、ＲＣＭはステップ３８３に進んで、ドメイ
ンがロック解除されるまで、呼出し側プロセスが待機し
たいか否かを決定する。そうでない場合は、ＲＣＭはル
ーチンから出る。そうである場合は、ＲＣＭはステップ
３８４に進んで、ドメインをロックしたプロセスに、別
のプロセスがそのドメインをロックしたいと望んでおり
、できるだけ早くそのドメインをロック解除すべきこと
をそのプロセスに知らせる信号を送る。そのプロセスに
、ステップ３８５で、ＧＵＡＲＤ＿ＤＯＭＡＩＮモジュ
ールを呼び出す。このモジュールは、先にそのドメイン
をロックしたプロセスがそのドメインをロック解除する
まで、呼出し側プロセスを待機状態にする。その後、現
在のＲＣＭが、呼出し側プロセスに対してそのドメイン
をロックし、このルーチンから出る。

【００５３】　　図２０は、流れ図の形のＵＮＬＯＣＫ
＿ＤＯＭＡＩＮ（ドメイン・ロック解除）手順である。 これは基本的に、ドメインをロック解除するためにＵＮ
ＧＵＡＲＤ＿ＤＯＭＡＩＮモジュールを呼び出すステッ
プ４０１だけからなっている。

【００５４】図２１は、グラフィックス障害ハンドラ４
０の流れ図である。グラフィックス障害は、グラフィッ
クス・プロセスが、アドレスすることを許可されていな
い装置またはドメインをアドレスしようと試みる際に発
生する。このような事象は、グラフィックス・プロセス
が、以前にスイッチ・アウトしたグラフィックス装置に
アクセスしようと試みているときに発生する。このグラ
フィックス障害は、割込みを発生する。第１レベルの割
込みハンドラが、まずこの割込みを処理し、第２レベル
の割込みハンドラに切り替わる。このグラフィックス障
害ハンドラは、第２レベルの割込みハンドラの１つであ
る。ステップ４２１で、ＲＣＭは、障害を発生している
プロセスがグラフィックス・プロセスであり、かつこの
障害が入出力障害であるか否かを決定する。そうでない
場合は、ＲＣＭはルーチンから出る。そうである場合は
、ＲＣＭはステップ４２２に進む。次にＲＣＭは、ステ
ップ４２２、４２３、４２４からなるループに入る。 このループは、障害の対象がどの装置であるかを決定す
る。それがどの装置に対するものでもない場合、ＲＣＭ
はステップ４２２でルーチンから出る。ステップ４２３
で、装置ごとに、装置特有の装置検査ルーチンを呼び出
す。障害が発生した場合、アドレスがグラフィックス障
害ハンドラに渡される。装置特有の装置検査モジュール
は、そのアドレスがその装置用のアドレス空間内にある
か否かを決定する。そうである場合は、ドメイン番号が
返される。次にステップ４２４で、ループを出るか否か
を決定する。ステップ４２５で、障害を発生しているプ
ロセスによってそのドメインがロックされているか否か
を決定する。そうである場合は、ＲＣＭはステップ４２
７に進む。そうでない場合は、ＲＣＭはステップ４２６
に進んで、ドメインがロックまたはガードされているか
、コンテキスト切替えが発生しているか、タイム・アウ
ト条件が発生したか、あるいは障害リストが空でないか
を決定する。これらの状況のうちのいずれかが真である
場合、ＲＣＭは、ステップ４３１に進んで、そのドメイ
ンが他のプロセスによってロックされているか否かを決
定する。そうでない場合は、ＲＣＭはステップ４２９に
進む。そうである場合は、障害ハンドラは、ドメインを
ロックしたプロセスに、ドメインをロック解除して、障
害を発生しているプロセスを実行させることができると
の信号を送る。次に障害ハンドラステップ４２９に進み
、そのドメインに対するそのプロセス用の現在の描出コ
ンテキストが、障害リストに加えられる。言い替えれば
、描出コンテキストが障害リストに加えられ、その結果
、後でそのコンテキストをそのドメインに切り替えるこ
とが可能になる。ステップ４２６の条件が真出ない場合
、ＲＣＭステップステップ４２７に進んで、障害を発生
しているプロセスの所有する描出コンテキストで、ドメ
インが延期されたか否かを決定する。（これは、たとえ
ば、あるプロセスがある装置をロックした後にそれをロ
ック解除し、それによってドメインをロックおよびロッ
ク解除するが、そのドメイン上でコンテキストを切り替
えないとき発生し得る。）そうでない場合は、ステップ
４２８で、ＲＣＭは、そのドメイン・コンテキストを、
障害を発生したプロセス用の現在の描出コンテキストに
切り替える。そうである場合は、ＲＣＭはステップ４３
０に進んで、そのプロセス用のドメインへのアクセスを
即座に許可し、そのドメインがもはや延期状態でないこ
とを示し、その後に、ＲＣＭはこのルーチンから出る。

【００５５】図２２は、タイマ・ハンドラ３４の流れ図
である。ステップ４４１で、現在のコンテキストが十分
長い間実行されたか否かを決定する。この決定は、その
プロセスがそのドメインを所有していたクロック時間や
、ドメインを所有した状態でそのプロセスが実行された
ＣＰＵサイクル数など、多数の要因に基づいて行なうこ
とができる。そうでない場合は、ステップ４４２でタイ
マを再起動し、ＲＣＭはルーチンから出る。そうである
場合は、ＲＣＭはステップ４４３に進み、ドメイン・タ
イマが停止したことを指示する。ステップ４４４で、そ
のドメインをロックまたはガードするために待機中の他
のプロセスがあるか否かを決定する。そうである場合は
、ステップ４４５で、これらのプロセスを覚醒させ（活
動化し）、タイマ・ハンドラから出る。そうでない場合
は、ステップ４４６で、ドメインがガードもロックもさ
れておらず、かつ障害リストが空でないか否かを決定す
る。これが真である場合、ＲＣＭはステップ４４７に進
んで、障害リストから次のプロセスを指名する。いずれ
も真でない場合は、タイマ・ハンドラから出る。

【００５６】図２３には、エグジット・ハンドラ４２の
流れ図が示されている。エグジット・ハンドラは、プロ
セスが自発的に終了しようとするとき、または非自発的
に終了させられるとき呼び出される。これは、このプロ
セスの残りの部分をすべて、ＲＣＭから取り除かなけれ
ばならないことを意味する。好ましい実施例では、エグ
ジット・ハンドラは、何らかの状態変化の場合に呼び出
される。ステップ４６１で、この状態変化がエグジット
状態への変化であるか否かを決定する。そうでない場合
は、ハンドラから出る。そうである場合は、ステップ４
６２で、このプロセスによって使用されたすべての資源
が、ＫＩＬＬ＿ＰＲＯＣＥＳＳ（プロセス・キル）モジ
ュールによって解放される。その後、ハンドラから出る
。ＫＩＬＬ＿ＰＲＯＣＥＳＳモジュールは、図６に示さ
れている。

【００５７】ヘビー・スイッチ・コントローラ３６が、
図２４に流れ図の形で示されている。ヘビー・スイッチ
・コントローラは、ループで効果的に動作している。ス
テップ４８１で、ＥＸＩＴ（出口）フラグがセットされ
たか否かを決定する。そうである場合は、ヘビー・スイ
ッチ・コントローラから出る。そうでない場合は、ヘビ
ー・スイッチ・コントローラは、ステップ４８２に進ん
で、コマンドを含む待ち行列要素を待つ。多重装置また
は多重ドメイン環境では、最初の描出コンテキスト切替
えを完了する前に、第２、第３などの描出コンテキスト
切替えを要求されることが有り得るので、ヘビー・スイ
ッチ・コントローラには待ち行列が必要である。好まし
い実施例では、待ち行列からのコマンドは、ＳＷＩＴＣ
Ｈ（切替え）またはＥＸＩＴ（エグジット）のいずれか
になる。ＳＷＩＴＣＨコマンドの場合、ブロック４８３
で、ＲＣＭは、装置特有のＥＮＤ＿ＳＷＩＴＣＨ（切替
え終了）モジュールを呼び出す。ＥＮＤ＿ＳＷＩＴＣＨ
モジュールは、装置特有の、時間のかかるタスク（ＤＭ
Ａ動作を開始した後に、ＤＭＡ動作の終了を待ちながら
休眠するなど）を実施する。装置特有のＥＮＤ＿ＳＷＩ
ＴＣＨが完了すると、ＲＣＭはステップ４８４に進んで
、描出コンテキスト切替えを完了するのに必要な、装置
独立な機能を実行する。これには、ドメイン用の現在の
コンテキストの設定、ドメイン・タイマのスタート、フ
ラグの設定などが含まれる。受け取ったコマンドがＥＸ
ＩＴである場合、ＲＣＭは、ステップ４８５に進んでＥ
ＸＩＴフラグをセットする。その結果、ヘビー・スイッ
チ・コントローラから出る。

【００５８】図２５には、機能ＧＵＡＲＤ＿ＤＯＭＡＩ
Ｎ（ドメイン・ガード）が示されている。このＧＵＡＲ
Ｄ＿ＤＯＭＡＩＮ機能は、１装置上の１ドメインを、ガ
ードし、ドメイン・ロックし、または装置ロックする。 ステップ５０１で、ＲＣＭは、ドメインがコンテキスト
切替え中であるかまたは他のプロセスによってすでにガ
ードされているか否か、あるいはタイマがオンであり呼
出し側がまだそのドメインを所有していないか否か、あ
るいはそのドメインが呼出し側以外のプロセスによって
ロックされているか否かを決定する。これらの条件のい
ずれかが真である場合、ＲＣＭはステップ５０２に進み
、そのドメインが、呼出し側がそのドメインをガードま
たはロックできる状態、すなわち前記の条件のすべてが
消えた状態になるまで、プロセスは休眠する。そうでな
い場合は、ＲＣＭはステップ５０３に進んで、呼出し側
がすでにそのドメインを所有しているか否かを決定する
。そうである場合は、ＲＣＭはステップ５０５に進む。 そうでない場合は、ＲＣＭはステップ５０４に進んで、
そのドメインにアクセスする許可をそれを所有している
プロセスから取り上げ、そのドメインが延期状態である
（すなわち、ドメイン上のコンテキストをそのドメイン
をガードまたはロックしたプロセスが所有していない状
態で、そのドメインがガードまたはロックされている）
ことを指示する。ステップ５０５で、ＲＣＭは、装置デ
ータ構造内のドメイン・アレイ内のドメイン・エントリ
で、そのドメインがガードされている（ＤＯＭＡＩＮ　
　ＧＵＡＲＤＥＤ）か、ドメイン・ロックされている（
ＤＯＭＡＩＮ　　ＬＯＣＫＥＤ）か、あるいは装置ロッ
クされている（ＤＯＭＡＩＮ　　ＤＥＶＩＣＥ　　ＬＯ
ＣＫＥＤ）かを示すフラグをセットする。この３者のう
ちのいずれであるかは、呼出し側によって指示される。 その後、このハンドラから出る。

【００５９】図２６には、ＵＮＧＵＡＲＤ＿ＤＯＭＡＩ
Ｎ（ドメイン・ガード解除）モジュールが、流れ図の形
で示されている。ステップ５２１で、ＲＣＭは、呼出し
側の指示に従って、ＤＯＭＡＩＮ　　ＧＵＡＲＤＥＤフ
ラグ（ドメイン・ガード済み）フラグ、ＤＯＭＡＩＮ　
　ＬＯＣＫＥＤ（ドメイン・ロック済み）フラグまたは
ＤＯＭＡＩＮ　　ＤＥＶＩＣＥ　　ＬＯＣＫＥＤ（ドメ
イン装置ロック済み）フラグのいずれかをクリアする。 ステップ５２２で、ドメイン・タイマがオフであり、か
つドメインがロックされていないか否かを決定する。タ
イマが進行中またはドメインがロックされている場合、
このモジュールから出る。タイマがオフでありかつドメ
インがロックされていない場合、ＲＣＭはステップ５２
３に進んで、そのドメインをガードまたはロックするた
めに待機中のプロセスがあるか否かを決定する。そうで
ある場合は、ＲＣＭはステップ５２４に進んで、そのド
メインをガードまたはロックするために待機中のプロセ
スを覚醒させ、このモジュールから出る。そうでない場
合は、ＲＣＭはステップ５２５に進んで、障害リストが
空であるか否かを決定する。障害リストが空である場合
、切り替えるべき描出コンテキストがないので、このモ
ジュールから出る。そうでない場合は、ＲＣＭはステッ
プ５２６に進んで、障害リスト中の次の描出コンテキス
トを指名する。その後、このハンドラから出る。

【００６０】図２７は、内部機能である描出コンテキス
ト切替えモジュールを示す流れ図である。ステップ５４
０で、ドメイン切替え中であることを示す標識をセット
し、ドメイン延期中であることを示す標識をクリアする
。これにより、そのドメインに対する追加のコンテキス
ト切替えを開始しようとする試みが抑止される。ステッ
プ５４１で、切替え先のプロセスが、すでにアダプタ上
にあるコンテキストを所有しているか否かを決定する。 そうである場合は、ＲＣＭはステップ５４３に進む。そ
うでない場合、ＲＣＭはステップ５４２に進んで、ドメ
イン上の現在のコンテキストを所有しているプロセスか
らドメインにアクセスする許可を取り上げ、新しい描出
コンテキストを所有しているプロセスに、そのドメイン
にアクセスする許可を与える。ステップ５４３で、その
ドメインに対する現在の描出コンテキストが、装置デー
タ構造用のドメイン・アレイ内のドメイン・エントリで
セットされ、新しい描出コンテキストの優先順位が調整
される（好ましい実施例では、格下げする）。 ステップ５４４で、ＲＣＭは、描出コンテキスト切替え
を開始するのに必要な装置特有の活動を実行する、装置
特有の機能ＳＴＡＲＴ＿ＳＷＩＴＣＨ（）を呼び出し、
このコンテキスト切替えに必要な作業量を決定する。こ
の機能は、使用中の装置特有の装置ドライバ・モジュー
ルである。ステップ５４５で、この切替えが（大量の作
業を必要としない）ライト・スイッチであるか否かを決
定する。そうである場合、ＳＴＡＲＴ＿ＳＷＩＴＣＨ（
）は、コンテキスト切替えを完了するのに必要な活動を
すべて完了しており、ＲＣＭはステップ５４６に進んで
、切替えを終了し、コンテキスト切替えを完了するのに
必要な装置独立な活動をすべて実行する、描出コンテキ
スト切替終了ルーチン（図３０）を呼び出す。その後、
このモジュールから出る。このプロセスが（長時間を要
する）ヘビー・スイッチである場合は、ＲＣＭはステッ
プ５４７に進んで、描出コンテキスト切替えモジュール
が割込みレベルから（すなわち、ハンドラのうちの１つ
から）呼び出されたか否かを決定する。そうである場合
は、ＲＣＭはステップ５４８に進んで、描出コンテキス
トをブロック済みにセットし、プロセスをブロックし、
ヘビー・スイッチ・コントローラの待ち行列にコンテキ
スト切替えコマンドを登録する。その後、このモジュー
ルから出る。描出コンテキスト切替えモジュールがハン
ドラから呼び出されなかった場合、ＲＣＭはステップ５
４９に進んで、そのドメインに対する描出コンテキスト
切替えを完了するのに必要なすべての活動を実行する、
装置特有のＥＮＤ＿ＳＷＩＴＣＨ（）モジュールを呼び
出す。この機能は、使用中の装置特有の装置ドライバ・
モジュールである。ステップ５５０で、ＲＣＭは描出コ
ンテキスト切替え終了モジュールを呼び出して、コンテ
キスト切替えを完了するのに必要な装置独立な活動を実
行する（図３０）。その後、このモジュールから出る。

【００６１】図２８は、描出コンテキスト指名モジュー
ルの流れ図である。ステップ５６１で、ＤＯＭＡＩＮ　
　ＳＷＩＴＣＨＩＮＧ（ドメイン切替え中）標識をセッ
トし、ＤＯＭＡＩＮ　　ＳＵＳＰＥＮＤＥＤ（ドメイン
延期中）標識をクリアする。ステップ５６２で、ＲＣＭ
は、第１の（優先順位が最高の）描出コンテキストへの
コンテキスト切替えを開始するために、それをドメイン
障害リストから取り除く。ステップ５６３で、そのドメ
インを現在所有しているプロセスがあるか否かを決定す
る。 そうでない場合は、ＲＣＭはステップ５６５に進む。そ
うである場合、ＲＣＭはステップ５６４に進んで、ドメ
インを所有しているプロセスから、そのドメインをアク
セスする許可を取り上げ、現在そのドメイン上にある描
出コンテキストの優先順位を調整する（好ましい実施例
では格下げする）。ステップ５６５で、ＲＣＭは、新し
い描出コンテキストを所有するプロセスに、そのドメイ
ンにアクセスする許可を与え、その描出コンテキストを
、そのドメインに対する現在の描出コンテキストとして
、装置データ構造のドメイン・アレイ内のドメイン・エ
ントリに記録する。ステップ５６６で、実際のコンテキ
スト切替えを開始し、それに必要な作業量を決定するた
めに、装置特有のＳＴＡＲＴ＿ＳＷＩＴＣＨ（）を呼び
出す。ステップ５６７で、それがライト・スイッチであ
るか否かを決定する。ライト・スイッチである場合、Ｒ
ＣＭはステップ５６８に進んで、描出コンテキスト切替
え終了モジュールを実行して、切替えを終了する。ステ
ップ５６７に戻って、この切替えがライト・スイッチで
はない（ヘビー・スイッチである）場合、ＲＣＭはステ
ップ５６９に進んで、この描出コンテキスト指名モジュ
ールが、割込みレベルから呼び出されたのか否かを決定
する。そうである場合、ＲＣＭは、ステップ５７０でヘ
ビー・スイッチ・コントローラの待ち行列にコンテキス
ト切替えコマンドを登録し、この機能から出る。そうで
ない場合は、ＲＣＭはステップ５７１に進んで、コンテ
キスト切替えに必要な装置特有の活動を完了させる、装
置特有の切替え終了モジュールを呼び出す。ステップ５
７２で、この機能は、描出コンテキスト切替えモジュー
ルを呼び出して、描出コンテキスト切替えを完了するた
めの装置独立な活動を実行する。その後、このモジュー
ルから出る。

【００６２】図２９は、描出コンテキスト障害リスト機
能を示す流れ図である。ステップ５８１で、描出コンテ
キストの優先順位に基づいて、そのドメイン用の障害リ
ストに描出コンテキストを登録する。これには、すでに
リスト上にある描出コンテキスト全体を検索して、すで
にリスト上にある描出コンテキストの優先順位に対する
その相対的優先順位に基づいて、リストに登録しようと
している新しい描出コンテキストの正しい位置を決定す
ることが含まれる。次にステップ５８２で、そのプロセ
スが待機するか否かを決定する。そうでない場合、ＲＣ
Ｍはステップ５８３に進んで、描出コンテキスト・デー
タ構造内でＲＣＸ　　ＢＬＯＣＫＥＤ（ブロック済み）
標識をセットし、次にその描出コンテキストを所有して
いるプロセスをブロックする（これは、グラフィックス
障害ハンドラから呼び出されたときに行なわれる）。そ
の後、この機能から出る。プロセスが、ブロックされず
待機する場合、ＲＣＭはステップ５８４に進んで、描出
コンテキスト・データ構造内でＲＣＸ　　ＷＡＩＴ（待
機中）標識をセットし、描出コンテキスト指名モジュー
ルによってこのプロセスが覚醒されるまで休眠する。そ
の後、この機能から出る。

【００６３】図３０は、描出コンテキスト切替え終了モ
ジュールを示す流れ図である。ステップ６０１で、ＤＯ
ＭＡＩＮ　　ＳＷＩＴＣＨＩＮＧ（ドメイン切替え中）
フラグがクリアされる。次にステップ６０２で、新しい
描出コンテキストの所有者によってそのドメインがロッ
クされているか否かを決定する。それが新しい描出コン
テキストの所有者によってロックされている場合、ＲＣ
Ｍはステップ６０４に進む。所有者によってロックされ
ていない場合は、ＲＣＭはステップ６０３に進んで、そ
の装置用のドメイン・アレイ内のドメイン・エントリで
ドメイン・タイマがオンであることを指示し、ドメイン
・タイマをスタートさせる。ステップ６０４で、プロセ
スがブロックされているか否かを決定する。そうである
場合、ＲＣＭはステップ６０５に進んで、ＲＣＸ　　Ｂ
ＬＯＣＫＥＤ標識をクリアし、そのプロセスをブロック
解除する。これによって、オペレーティング・システム
はそのプロセスを実行できるようになる。その後、描出
コンテキスト切替え終了プロセスから出る。ステップ６
０４に戻って、プロセスがブロックされていない場合、
ＲＣＭはステップ６０６に進んで、そのプロセスが休眠
中（待機中）であるか否かを決定する。そうである場合
、ＲＣＭはステップ６０７に進んで、ＲＣＸＷＡＩＴ標
識をクリアし、プロセスを覚醒させる。その後、描出コ
ンテキスト切替え終了プロセスから出る。そうでない場
合は、描出コンテキスト切替え終了プロセスから出る。

【００６４】図３１は、ＲＣＭおよびＲＣＭに関連する
事象ハンドラ３８とともに働くように構成された割込み
ハンドラを示す流れ図である。このような割込みハンド
ラはまったく装置特有であるが、図３１は、このような
割込みハンドラをどのように構成すべきかを示す１例で
ある。この図３１の割込みハンドラは、実際に最初に割
込み信号を処理する第１レベルの割込みハンドラによっ
て呼び出されるので、「第２レベル割込みハンドラ」と
呼ぶ。ステップ８０１で、このハンドラは、割込みの原
因が、この割込みハンドラによって処理される（割込み
ハンドラのサービスを受ける装置に対する）ものである
か否かを決定する。そうでない場合、ハンドラはステッ
プ８０２に進んで、その割込みがこの割込みハンドラに
よって処理されないことを指示し、このハンドラから出
る。ステップ８０１の後、割込みの原因が、この割込み
ハンドラによって処理されるものである場合、先に進ん
で、通常は装置からの状況を読み取ることによって、具
体的な原因を決定する。装置からの割込みの原因は、装
置によって大いに変わる。図３１に例示した原因は、多
くの表示装置に共通な例である。第１の原因８０３は、
装置の垂直同期期間が開始したことである。多くの表示
装置では、ユーザに異常が見えないようにするため、カ
ラー・ルックアップ・テーブルのロードなどある種の動
作を垂直同期期間中に行なう必要がある。これは装置に
よって決まる条件であり、垂直同期期間中に処理を行な
う必要がない装置もある。この処理が完了すると、ハン
ドラは、ステップ８１４に進む。ステップ８０４では、
割込みを発生させた原因は、ある装置の動作が完了した
ことである。これには、ＤＭＡ動作や、ビット・ブロッ
ク転送動作などが含まれる。この場合も割込みハンドラ
は、その割込みにサービスするのに必要なすべての活動
を行なう。コンテキスト切替えの実行にＤＭＡ動作を必
要とする装置の場合、ステップ８１０で、割込みハンド
ラは、ヘビー・スイッチ・コントローラがＤＭＡ動作の
完了を待機中であるか否かを決定する。そうである場合
、ハンドラは、ヘビー・スイッチ・コントローラを覚醒
させ、ステップ８１４に進む。ステップ８０５では、割
込みの原因はピック割込みであり、やはり割込みハンド
ラは、その割込みにサービスするために、装置特有の活
動を行なう。これには、装置からピック情報を検索する
こと、およびそれを事象ハンドラによって供給されるバ
ッファにセーブすること（図３２、３４、３５、３６、
３７、３８、３９参照）が含まれる。ステップ８１１で
、ハンドラは、このピック割込みが、ピック事象（ピッ
クのすべてが完了した）が発生したことを示しているか
否かを決定する。そうでない場合、ハンドラはステップ
８１８に進む。そうである場合、ハンドラはステップ８
１４に進む。図示の３つの具体的な割込みは、割込み全
般を代表するものであることに留意されたい。垂直同期
割込みは、装置へのデータ出力を必要とすることがある
。動作完了割込みは、特定の情況の下で、ヘビー・スイ
ッチ・コントローラを覚醒させることを必要とする。ピ
ック割込サービスは、一部の割込みがどうして事象とし
て解釈されないかを示している。当業者なら理解できる
ように、８０３、８０４、８０５の割込み条件など、他
の割込み条件をこの割込みハンドラに含めることもでき
る。ステップ８１４で、割込みハンドラは、プロセスが
、発生したばかりの事象に関する通知を受けたいか否か
を決定する。事象ハンドラは、この割込みハンドラと通
信する装置特有のルーチンを呼び出して、そのプロセス
がどの事象について知りたいと望んでいるかを割込みハ
ンドラに通知する。プロセスがこの事象について知りた
くない場合、ハンドラはステップ８１８に進む。 プロセスがこの事象について知りたいと望んでいる場合
、ハンドラは、ステップ８１６で、プロセスが同期式通
知を要求したか否かを決定する。そうである場合、ステ
ップ８１５で、ハンドラは、休眠中のプロセスを覚醒し
、その後ステップ８１７に進む。そうでない場合、ハン
ドラは単にステップ８１７に進み、事象ハンドラによっ
て供給されるＣＡＬＬＢＡＣＫ機能（図３８参照）を呼
び出して、ＲＣＭ事象・データ構造内に事象情報を記録
（図３２参照）する。ハンドラはステップ８１８に進ん
で、この割込みが処理済みであることを示し、その後ハ
ンドラから出る。

【００６５】図３２は、事象処理に関連するデータ構造
を示す。まず、図３１の割込みハンドラによって処理さ
れる割込みと、図３３、３５、３６、３７、３８、３９
に示す事象ハンドラによって管理される事象を区別しな
ければならない。割込みとは、装置が電気信号を発生し
、ＣＰＵがそれを検出することによって引き起こされる
、通常のＣＰＵ命令の流れの中断である。割込みハンド
ラは、割込み可能にされている割込みをすべて処理しな
ければならない。事象とは、アプリケーション・プロセ
スが、それが発生したことなどそれに関する情報と、そ
の事象に関連するデータを要求する、論理的な出来事で
ある。割込みのすべてが事象とは限らないので、この区
別を行なわなければならない。垂直同期割込みを考えて
みよう。多くの場合、プロセスはそれについてまったく
知りたいと思わない。しかし、垂直ブランキング期間と
同期させなければならない特定の活動を行なう場合、ア
プリケーションは垂直同期割込みを待ちたいと望む。 この場合、それは１つの事象になる。もう１つの例とし
て、ピック・ヒット（直線などのグラフィック・オブジ
ェクトが、アプリケーション・プログラムで定義したピ
ック空間に含まれるとき）を緩衝記憶しなければならな
いアダプタのピック動作と、バッファが満杯になって、
割込みハンドラがそのバッファを読み取れるようになっ
たときの割込みを考えてみよう。最終的にはアプリケー
ション・プロセスはピック動作を終了し、その後装置は
別のピック割込みを発生する。今回は、ピックが終了し
たことを示す標識付きの割込みである。このような場合
には、アプリケーション・プログラムはすべての中間ピ
ック割込みについて知りたいわけではなくて、ピック完
了事象について知りたいと望む。プロセスは、事象を同
期または非同期の発生として取り扱える。同期式事象の
場合、プロセスは、事象ハンドラに、その事象が発生す
るまでそのプロセスを待機（休眠）させるように要求す
る。非同期式事象の場合、プロセスは、事象ハンドラに
その事象が発生した時にそのプロセスに通知するように
要求し、そのプロセスはその事象を待たずに他の作業の
実行を続ける。非同期式の通知には、マルチタスク式オ
ぺレーティング・システムに共通の信号機構を用いる。 たとえば、プロセスは、ある事象を非同期的に扱いたい
と事象ハンドラに伝えるために、グラフィックス・シス
テム・コールを行なうことができる。このシステム・コ
ールから戻った後、そのプロセスは、データ構造の走査
、計算などの作業を続けることができる。事象が発生し
た時、事象ハンドラは、プロセスに信号を送る。このプ
ロセスは、信号ハンドラ（命令処理の主流から外れて動
作するアプリケーション機能。ソフトウェア割込みハン
ドラに多少類似している。）を定義していなければなら
ない。オペレーティング・システムは、このプロセスの
信号ハンドラにその信号を送る。信号ハンドラは、信号
ハンドラとアプリケーション・プロセスの主部分の両方
からアクセスできるデータ構造内に、何らかのフラグを
セットすることができる。プロセスは、周期的にそのフ
ラグを検査し、それがセットされていると分かったとき
、事象ハンドラを呼び出して、どの事象が発生したのか
を突き止めることができる。

【００６６】図３２に戻って、装置プロセス・ブロック
８２０は、図４の装置プロセス・ブロック６２に対応す
るもので、装置プロセス・ブロック８２０に対応する装
置に対するプロセス用のすべての事象情報に対する固定
位置として働く、事象情報構造８２２を含んでいる。事
象情報構造８２２は、最終事象構造（直前の事象）８２
４へのリンクを含んでいる。この構造は、最後の同期式
事象を識別するフィールドとその事象からの少量の情報
を含んでいる。事象情報構造８２２は、事象アレイ８２
６へのリンクを含んでいる。事象アレイ８２６のサイズ
は、アプリケーション・プロセスによって決定される。 事象アレイ８２６内の各エントリは、最終事象構造８２
４と同一の情報を含んでいる。事象アレイは、アプリケ
ーション・プロセスに非同期的に報告された事象に関す
る情報を記録するために用いられる。アレイが必要なの
は、プロセスが、複数の事象を非同期的に報告するよう
要求することができ、かつ事象ハンドラがそのプロセス
に信号を送ってから、プロセスが実際に事象アレイ８２
６から事象情報を読み取るまでの間に、複数の事象が発
生し得るためである。最後に、事象情報構造８２２は、
事象データ・バッファ８２８へのリンクを含んでいる。 このバッファは、アプリケーション・プロセスが要求す
るサイズのもので、ある種の事象、たとえばピック動作
などからの大量のデータを保持するために用いられる。 このバッファは、事象処理に必要な資源が最小になるよ
うに、アプリケーション・プロセスから要求があった時
点で、事象ハンドラによって動的に生成され破壊される
。

【００６７】図３３は、ＡＳＹＮＣ＿ＥＶＥＮＴ（非同
期事象）モジュールの流れ図を示す。プロセスは、非同
期的に通知してほしい事象を指示するためにこのモジュ
ールを呼び出す。ステップ８３０で、事象ハンドラは、
呼出し側プロセスが事象を要求していないか否かを決定
する。そうである場合、ステップ８３２で、事象ハンド
ラは、装置特有のＡＳＹＮＣ＿ＭＡＳＫ（）を呼び出し
て、非同期の事象報告をディスエーブルし、次にステッ
プ８３４で、事象ハンドラは事象アレイを保持するため
に用いられた記憶域をすべて解放し、戻る。ステップ８
３０で、プロセスが、１つまたは複数の事象に関して非
同期的に通知するように要求していた場合、ステップ８
３６で、事象ハンドラは、アプリケーション・プロセス
の要求したサイズの事象アレイ用の記憶域を割り振って
ピン付けし、この事象アレイを装置プロセス・データ構
造内の事象情報構造にリンクする。次にステップ８３８
で、事象ハンドラは、装置特有のＡＳＹＮＣ＿ＭＡＳＫ
（）を呼び出し、事象ハンドラのＣＡＬＬＢＡＣＫ機能
のアドレスを渡して、アプリケーションの要求した事象
の非同期の報告をイネーブルし、その後戻る。

【００６８】図３４は、ＥＮＡＢＬＥ＿ＩＮＴＲ（割込
みイネーブル）モジュールの流れ図を示す。プロセスは
、表示装置の割込みをイネーブルまたはディスエーブル
するためにこのモジュールを呼び出す。ステップ８４０
で、事象ハンドラは装置特有のＥＮＡＢＬＥ＿ＩＮＴＳ
（）を呼び出して、アプリケーション・プログラムの指
示した割込みだけをイネーブルし、他のすべてをディス
エーブルする。これによって、割込みが事象として報告
されずに発生できるようになる。

【００６９】図３５は、ＥＶＥＮＴ＿ＢＵＦＦＥＲ（事
象バッファ）モジュールの流れ図を示す。プロセスは、
ある事象からの大量のデータを報告するための事象バッ
ファを作成するためにこのモジュールを呼び出す。ステ
ップ８５０で、事象ハンドラは、現在バッファが存在す
るか否かを検査する。そうである場合、事象ハンドラは
バッファを１つだけしか扱えないので、ステップ８５０
でそのバッファをピン解除して解放し、ステップ８５４
に進む。そうでない場合は、ステップ８５４で、事象ハ
ンドラは、アプリケーション・プロセスの要求するサイ
ズの事象バッファを割り振ってピン付けし、それを装置
プロセス・データ構造内の事象情報構造にリンクする。

【００７０】図３６は、ＧＥＴ＿ＥＶＥＮＴＳ（事象獲
得）モジュールの流れ図を示す。プロセスは、発生した
非同期事象に関する情報を検索するためにこのモジュー
ルを呼び出す。ステップ８６０で、事象ハンドラは、事
象アレイ内の有効なすべてのエントリを、アプリケーシ
ョン・プロセスが提供するバッファにコピーする。ステ
ップ８６２で、事象数を０にセットして、すべての事象
をアプリケーション・プロセスが受け取ったことをマー
クし、戻る。

【００７１】図３７は、ＷＡＩＴ＿ＥＶＥＮＴ（事象待
機）モジュールの流れ図を示す。プロセスは、同期事象
の発生を待つ、事象バッファを検索するなどのために、
このモジュールを呼び出す。ステップ８７０で、事象ハ
ンドラは、呼出し側プロセスが事象の発生を待つことを
望んでいるのか否かを決定する。そうである場合、ステ
ップ８７４で、装置特有のＳＹＮＣ＿ＭＡＳＫ（）を呼
び出し、プロセスがその発生を待つことを望んでいる事
象と、事象ハンドラに事象を報告するために割込みハン
ドラが用いる事象ハンドラのＣＡＬＬＢＡＣＫ機能とを
パラメータとして渡す。呼出し側プロセスは、１つの事
象が発生したとき、割込みハンドラによって覚醒される
まで休眠する。次にステップ８７８で、事象ハンドラは
、事象が事象バッファに入っているか否かを検査する。 そうである場合、ステップ８８２で、事象ハンドラは、
事象バッファをアプリケーション・プロセスが提供する
バッファにコピーし、ステップ８８６に進む。そうでな
い場合は、ステップ８８６に進む。ステップ８８６で、
事象ハンドラは、事象情報、たとえば事象のタイプなど
と、事象からの少量のデータを、呼出し側プロセスが提
供するバッファにコピーする。これによって、プロセス
は、待っている複数の事象のうちのどれが実際に発生し
たのかを決定できる。ステップ８７０に戻って、呼出し
側プロセスが事象の発生を待っていない場合、事象ハン
ドラは、ステップ８７２に進み、呼出し側プロセスがい
ずれかの事象に関して知りたいと望んでいるか否かを決
定する。そうである場合、ステップ８８８に進んで、装
置特有のＳＹＮＣ＿ＭＡＳＫ（）を呼び出し、呼出し側
プロセスが知りたい事象と、ＣＡＬＬＢＡＣＫ（）機能
（図３８参照）のアドレスとを渡して、割込みハンドラ
が、その事象に関する情報を事象ハンドラに通知できる
ようにし、戻る。ステップ８７２に戻って、呼出し側プ
ロセスが事象に関して通知することを要求していない場
合は、そのプロセスが事象データの検索を望んでいるこ
とを意味し、ステップ８７６で、事象ハンドラは、呼出
し側プロセスが提供するバッファに最終事象構造をコピ
ーする。ステップ８８０で、このモジュールは、この事
象に事象バッファが関連づけられているか否かを決定す
る。そうでない場合、このモジュールは戻る。そうであ
る場合、ステップ８８４で、このモジュールは、アプリ
ケーション・プロセスが提供するバッファに事象バッフ
ァをコピーし、戻る。

【００７２】図３８は、ＣＡＬＬＢＡＣＫ（コールバッ
ク）モジュールの流れ図を示す。装置割込みハンドラが
、同期式または非同期式の事象に関する情報を事象ハン
ドラに通知するために、このモジュールを呼び出す。 ＣＡＬＬＢＡＣＫモジュールは、ステップ９００で、事
象を同期式、非同期式のどちらで報告するかを決定する
。同期式の場合、ＣＡＬＬＢＡＣＫモジュールは、ステ
ップ９０２で、割込みハンドラから渡された事象情報を
、最終事象構造にコピーする。次にステップ９１０で、
ＣＡＬＬＢＡＣＫモジュールは、プロセスがその事象を
待機中（休眠中）であるか否かを決定する。そうでない
場合、このモジュールは戻る。そうである場合、ステッ
プ９１２で、ＣＡＬＬＢＡＣＫモジュールは、そのプロ
セスに信号を送ってその事象の発生を通知し、戻る。ス
テップ９００に戻って、事象を非同期式に報告する場合
、ステップ９０４で、ＣＡＬＬＢＡＣＫモジュールは、
事象アレイが満杯であるか否かを決定する。そうである
場合、ステップ９０８で、このモジュールは、事象アレ
イがオーバフローしたことを示すフラグをセットし、ス
テップ９１４に進む。そうでない場合、このモジュール
は、ステップ９０６でその事象に関する情報を事象アレ
イ内に記憶し、ステップ９１４に進む。そのステップで
，ＣＡＬＬＢＡＣＫモジュールは、この事象が事象アレ
イ内の先頭であるか否かを決定する。そうでない場合、
このモジュールは戻る。そうである場合、ステップ９１
６で、このモジュールはプロセスに信号を送って、その
事象の発生を示し、戻る。

【００７３】

【発明の効果】本発明によって、第１および第２のポー
トを有する周辺装置を少なくとも１つ含む、複数のプロ
セスを実行するための、マルチタスク式データ処理シス
テムが提供される。ある周辺装置全体を制御するための
周辺装置へのアクセス権を、１つのプロセスだけに与え
る能力を含む周辺装置マネジャが提供される。この周辺
マネジャは、第１のプロセスに周辺装置の１つのポート
へのアクセス権を与え、それとは独立にかつ同時に、第
２のプロセスにその周辺装置の第２のポートへのアクセ
ス権を与える能力をも含んでいる。

【図面の簡単な説明】

【図１】本発明が適用される、表示装置に接続された中
央演算処理装置のブロック図である。

【図２】本発明の実施例になる、描出コンテキスト・マ
ネジャ（ＲＣＭ）のブロック図である。

【図３】描出コンテキスト・マネジャのシステム・コー
ル機能の流れ図である。

【図４】描出コンテキスト・マネジャのデータ構造を示
すブロック図である。

【図５】ＭＡＫＥ＿ＧＰ（グラフィックス・プロセス作
成）モジュールの流れ図である。

【図６】ＵＮＭＡＫＥ＿ＧＰ（グラフィックス・プロセ
ス削除）モジュールの流れ図である。

【図７】ＣＲＥＡＴＥ　　ＲＥＮＤＥＲＩＮＧ　　ＣＯ
ＮＴＥＸＴ（描出コンテキスト作成）モジュールの流れ
図である。

【図８】ＤＥＬＥＴＥ　　ＲＥＮＤＥＲＩＮＧ　　ＣＯ
ＮＴＥＸＴ（描出コンテキスト削除）モジュールの流れ
図である。

【図９】ＢＩＮＤ（バインド）モジュールの流れ図であ
る。

【図１０】ＳＥＴ＿ＲＣＸ（描出コンテキスト設定）モ
ジュールの流れ図である。

【図１１】ＣＲＥＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲ（サ
ーバ属性作成）モジュールの流れ図である。

【図１２】ＤＥＬＥＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲ（サ
ーバ属性削除）モジュールの流れ図である。

【図１３】ＵＰＤＡＴＥ＿ＳＥＲＶＥＲ＿ＡＴＴＲ（サ
ーバ属性更新）モジュールの流れ図である。

【図１４】ＣＲＥＡＴＥ＿ＣＬＩＥＮＴ＿ＡＴＴＲ（ク
ライアント属性作成）モジュールの流れ図である。

【図１５】ＤＥＬＥＴＥ＿ＣＬＩＥＮＴ＿ＡＴＴＲ（ク
ライアント属性削除）モジュールの流れ図である。

【図１６】ＵＰＤＡＴＥ＿ＣＬＩＥＮＴ＿ＡＴＴＲ（ク
ライアント属性更新）モジュールの流れ図である。

【図１７】ＬＯＣＫ＿ＤＥＶＩＣＥ（デバイス・ロック
）モジュールの流れ図である。

【図１８】ＵＮＬＯＣＫ＿ＤＥＶＩＣＥ（デバイス・ロ
ック解除）モジュールの流れ図である。

【図１９】ＬＯＣＫ＿ＤＯＭＡＩＮ（ドメイン・ロック
）モジュールの流れ図である。

【図２０】ＵＮＬＯＣＫ＿ＤＯＭＡＩＮ（ドメイン・ロ
ック解除）モジュールの流れ図である。

【図２１】グラフィックス障害ハンドラの流れ図である
。

【図２２】タイマ・ハンドラの流れ図である。

【図２３】エグジット・ハンドラの流れ図である。

【図２４】ヘビー・スイッチ・コントローラ・モジュー
ルの流れ図である。

【図２５】ＧＵＡＲＤ＿ＤＯＭＡＩＮ（ドメイン・ガー
ド）モジュールの流れ図である。

【図２６】ＵＮＧＵＡＲＤ＿ＤＯＭＡＩＮ（ドメイン・
ガード解除）モジュールの流れ図である。

【図２７】描出コンテキスト切替えモジュールの流れ図
である。

【図２８】描出コンテキスト切替えモジュールの流れ図
である。

【図２９】描出コンテキスト障害リスト・モジュールの
流れ図である。

【図３０】描出コンテキスト切替え終了モジュールの流
れ図である。

【図３１】　割込みハンドラの流れ図である。

【図３２】描出コンテキスト・マネジャの、事象処理に
関連するデータ構造を示すブロック図である。

【図３３】ＡＳＹＮＣ＿ＥＶＥＮＴ（非同期事象）モジ
ュールの流れ図である。

【図３４】ＥＮＡＢＬＥ＿ＩＮＴＲ（割込みイネーブル
）モジュールの流れ図である。

【図３５】ＥＶＥＮＴ＿ＢＵＦＦＥＲ（事象バッファ）
モジュールの流れ図である。

【図３６】ＧＥＴ＿ＥＶＥＮＴＳ（事象獲得）モジュー
ルの流れ図である。

【図３７】ＷＡＩＴ＿ＥＶＥＮＴ（事象待機）モジュー
ルの流れ図である。

【図３８】事象ハンドラのＣＡＬＬＢＡＣＫ（コールバ
ック）機能モジュールの流れ図である。

【符号の説明】

１０　　中央演算処理装置 １２　　表示装置 １４　　Ｘサーバ ２２　　描出コンテキスト・マネジャ（ＲＣＭ）３０　
　アプリケーション・コード ３２　　ＲＣＭシステム・コール ３４　　タイマ・ハンドラ ３６　　ヘビー・スイッチ・コントローラ（カーネル・
プロセス） ３８　　事象ハンドラ ４０　　グラフィックス障害ハンドラ ４２　　エグジット・ハンドラ ４４　　ＲＣＭデータ

Claims (24)

【特許請求の範囲】
1. 【請求項１】第１および第２ポートを有する周辺装置を
   少なくとも１つ含む、複数のプロセスを実行するための
   、マルチタスク式データ処理システムにおいて、周辺装
   置を制御するための周辺装置への排他的アクセス権を、
   １つのプロセスだけに与える手段と、第１プロセスに周
   辺装置の一方のポートへの排他的アクセス権を与え、第
   ２プロセスにその周辺装置のもう一方のポートへの独立
   かつ同時のアクセス権を与える手段と、を含む、周辺装
   置マネジャを備えたマルチタスク式データ処理システム
   。
2. 【請求項２】さらに、それぞれのコンテキストが前記周
   辺装置の独立な状態を定義し、かつそれぞれのコンテキ
   ストが前記プロセスのうちの１つによって定義される、
   複数のコンテキストを記憶する手段を含むことを特徴と
   する、請求項１に記載のマルチタスク式データ処理シス
   テム。
3. 【請求項３】さらに、それぞれのドメインが前記周辺装
   置の一方のポートの独立な状態を定義し、かつそれぞれ
   のドメインが前記プロセスのうちの１つによって定義さ
   れる、複数のドメインを記憶する手段を含むことを特徴
   とする、請求項２に記載のマルチタスク式データ処理シ
   ステム。
4. 【請求項４】さらに、プロセス従属／装置情報を提供す
   る第１の複数のデータを記憶する手段を含むことを特徴
   とする、請求項３に記載のマルチタスク式データ処理シ
   ステム。
5. 【請求項５】さらに、プロセス独立／装置従属情報を提
   供する第２の複数のデータを記憶する手段を含むことを
   特徴とする、請求項３に記載のマルチタスク式データ処
   理システム。
6. 【請求項６】さらに、全プロセスおよび全装置に共通の
   情報を提供する第３の複数のデータを記憶する手段を含
   むことを特徴とする、請求項３に記載のマルチタスク式
   データ処理システム。
7. 【請求項７】さらに、あるプロセスが排他的アクセス権
   を有するポートに別のプロセスがアクセスしようと試み
   た場合に、前者のプロセスにその旨を通知する手段を含
   むことを特徴とする、請求項３に記載のマルチタスク式
   データ処理システム。
8. 【請求項８】さらに、あるプロセスが排他的アクセス権
   を有する装置に別のプロセスがアクセスしようと試みた
   場合に、前者のプロセスにその旨を通知する手段を含む
   ことを特徴とする、請求項３に記載のマルチタスク式デ
   ータ処理システム。
9. 【請求項９】第１および第２ポートを有する周辺装置を
   少なくとも１つ含む、複数のプロセスを実行するための
   、マルチタスク式データ処理システムにおいて、周辺装
   置を制御するための周辺装置への排他的アクセス権を、
   １つのプロセスだけに与えるステップと、第１プロセス
   に、情報を転送するための周辺装置の一方のポートへの
   アクセス権を与え、第２プロセスに、情報を転送するた
   めのその周辺装置のもう一方のポートへの独立かつ同時
   のアクセス権を与えるステップと、を含むことを特徴と
   する、前記周辺装置とインタフェースする方法。
10. 【請求項１０】さらに、それぞれのコンテキストが前記
    周辺装置の独立な状態を定義し、かつそれぞれのコンテ
    キストが前記プロセスのうちの１つによって定義される
    、複数のコンテキストを記憶するステップを含むことを
    特徴とする、請求項９に記載の前記周辺装置とインタフ
    ェースする方法。
11. 【請求項１１】さらに、それぞれのドメインが前記周辺
    装置の一方のポートの独立な状態を定義し、かつそれぞ
    れのドメインが前記プロセスのうちの１つによって定義
    される、複数のドメインを記憶するステップを含むこと
    を特徴とする、請求項９に記載の前記周辺装置とインタ
    フェースする方法。
12. 【請求項１２】さらに、プロセス従属／装置情報を提供
    する第１の複数のデータを記憶するステップを含むこと
    を特徴とする、請求項９に記載の前記周辺装置とインタ
    フェースする方法。
13. 【請求項１３】さらに、プロセス独立／装置従属情報を
    提供する第２の複数のデータを記憶するステップを含む
    ことを特徴とする、請求項９に記載の前記周辺装置とイ
    ンタフェースする方法。
14. 【請求項１４】さらに、全プロセスおよび全装置に共通
    の情報を提供する第３の複数のデータを記憶するステッ
    プを含むことを特徴とする、請求項９に記載の前記周辺
    装置とインタフェースする方法。
15. 【請求項１５】さらに、あるプロセスが排他的アクセス
    権を有するポートに別のプロセスがアクセスしようと試
    みた場合に、その旨を前者のプロセスに通知するステッ
    プを含むことを特徴とする、請求項９に記載の前記周辺
    装置とインタフェースする方法。
16. 【請求項１６】さらに、あるプロセスが排他的アクセス
    権を有する装置に別のプロセスがアクセスしようと試み
    た場合に、その旨を前者のプロセスに通知するステップ
    を含むことを特徴とする、請求項９に記載の前記周辺装
    置とインタフェースする方法。
17. 【請求項１７】複数のプロセスおよび周辺装置マネジャ
    を含むマルチタスク式データ処理システムであって、前
    記の複数のプロセスおよび前記周辺装置マネジャを実行
    するための中央処理手段と、それぞれのポートが前記中
    央処理手段から情報を受け取り、また前記中央処理手段
    へ情報を提供するように接続されている、第１および第
    ２のポートを含む、データ処理機能を実行するための周
    辺装置手段とを含み、前記周辺装置マネジャが、周辺装
    置を制御するための周辺装置へのアクセス権を１つのプ
    ロセスだけに与える手段と、第１プロセスに周辺装置の
    一方のポートにアクセスするためのアクセス権を与え、
    第２プロセスにその周辺装置のもう一方のポートへの独
    立かつ同時のアクセス権を与える手段とを含むことを特
    徴とする、マルチタスク式データ処理システム。
18. 【請求項１８】前記周辺マネジャがさらに、それぞれの
    コンテキストが前記周辺装置の独立な状態を定義し、か
    つそれぞれのコンテキストが前記プロセスのうちの１つ
    によって定義される、複数のコンテキストを記憶する手
    段を含むことを特徴とする、請求項１７に記載のマルチ
    タスク式データ処理システム。
19. 【請求項１９】前記周辺マネジャがさらに、それぞれの
    ドメインが前記周辺装置の一方のポートの独立な状態を
    定義し、かつそれぞれのドメインが前記プロセスのうち
    の１つによって定義される、複数のドメインを記憶する
    手段を含むことを特徴とする、請求項１８に記載のマル
    チタスク式データ処理システム。
20. 【請求項２０】前記周辺マネジャがさらに、プロセス従
    属／装置情報を提供する第１の複数のデータを記憶する
    手段を含むことを特徴とする、請求項１９に記載のマル
    チタスク式データ処理システム。
21. 【請求項２１】前記周辺マネジャがさらに、プロセス独
    立／装置従属情報を提供する第２の複数のデータを記憶
    する手段を含むことを特徴とする、請求項１９に記載の
    マルチタスク式データ処理システム。
22. 【請求項２２】前記周辺マネジャがさらに、全プロセス
    および全装置に共通の情報を提供する第３の複数のデー
    タを記憶する手段を含むことを特徴とする、請求項１９
    に記載のマルチタスク式データ処理システム。
23. 【請求項２３】前記周辺マネジャがさらに、あるプロセ
    スが排他的アクセス権を有するポートに別のプロセスが
    アクセスしようと試みた場合に、その旨を前者のプロセ
    スに通知する手段を含むことを特徴とする、請求項１９
    に記載のマルチタスク式データ処理システム。
24. 【請求項２４】前記周辺マネジャがさらに、あるプロセ
    スが排他的アクセス権を有する装置に別のプロセスがア
    クセスしようと試みた場合に、その旨を前者のプロセス
    に通知する手段を含むことを特徴とする、請求項１９に
    記載のマルチタスク式データ処理システム。