JPH0831038B2 - 割込みマネジャおよび割込み処理方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】現代のデータ処理システムは、割込み発
生能力を備えている。割込みとは、（パワー・ダウンな
ど）事前に設定された事象の発生時に立ち上がる信号で
ある。割込みは一般に、ハードウェアの現在の状態を決
定するために、ソフトウェアが使用する。しかし、デー
タ処理装置内での現在の処理の実行に直接影響しないか
もしれない割込みを首尾一貫して監視することは、ソフ
トウェアの無駄であることが多い。

【０００３】この分野の技法の従来技術には、フォール
ヒース（Voorhies）、カーク（Kirk）、ラスロップ（La
throp）の論文、“Virtual Graphics”, Computer Grap
hics, Vol.22,No.4,１９８８年８月がある。この論文
は、単一のタスク本位のグラフィックス・ディスプレイ
・アダプタを含む多重プロセス・ワークステーションを
対象としている。この論文は、ディスプレイ・アダプタ
のコンテキストを速やかに切り替える問題を対象として
いる。これは、グラフィック所有権違反（あるグラフィ
ックス・プロセスが、アクセス権を持たない装置にアク
セスを試みた）の検出に基づくコプロセッサ例外、ハー
ドウェア内での描画コンテキストの効率的なスワッピン
グ、コマンド・フロー制御に基づく例外、ウィンドウ境
界内での描画のクリッピング、および画素フォーマット
と画素用ルックアップ・テーブルの切替えを用いること
で達成される。この参照文献は、追加のハードウェア
が、ディスプレイ・コンテキストの速やかな切替えとい
う問題の部分的解決策となることを教示している。

【０００４】ローデン（Rhoden) とウィルコックス（Wi
lcox）の論文“Hardware Acceleration for Windows Sy
stem”Computer Graphics,Vol.23,No.3,１９８９年７月
は、多重ウィンドウ処理機を提供するためのハードウェ
ア実施様態を示している。

【０００５】“Virtual Machine Interface/Virtual Re
source Manager”，ＩＢＭテクニカル・ディスクロージ
ャ・ブルテン，Vol.30,No.1,１９８７年６月は、仮想マ
シン用のコンテキスト切替機構を開示している。この参
照文献では、中央演算処理装置に対する完全なコンテキ
ストが切り替えられる。

【０００６】“Screen-Sharing Ring for Enhanced Mul
tiple Application Display”，ＩＢＭテクニカル・デ
ィスクロージャ・ブルテン，Vol.28,No.8,１９８６年１
月は、専用の長方形サブエリア内に表示されるディスプ
レイ・ウィンドウをレイアウトするための技法を開示し
ている。

【０００７】“Asynchronous Data Transfer Buffer fo
r NP Systems”，ＩＢＭテクニカル・ディスクロージャ
・ブルテン, Vol.25,No.8,１９８３年１月は、プロセッ
サが互いに通信して、共通の私用メモリにアクセスする
際に競合が発生しないようにする、多重処理通信システ
ムを開示している。

【０００８】“Hardware Display Windowing Syste
m”，ＩＢＭテクニカル・ディスクロージャ・ブルテ
ン，Ｖｏｌ．２８，Ｎｏ．１２，１９８６年５月は、多
重プロセッサによって共用される表示装置と共に用いる
ハードウェア・ウィンドウ処理システムを開示してい
る。

【０００９】“Multiprocessor System to Improve Con
text Switching”，ＩＢＭ テクニカル・ディスクロー
ジャ・ブルテン，Vol.27,No.5,１９８４年１０月は、一
時に１台のプロセッサだけが活動状態であると指定する
ことによって、コンテキストの切替えを減らす処理シス
テムを開示している。

【００１０】“Multi-Tasking Using Co-Equal Multipr
ocessors Having Memory-Lock Facilities”，ＩＢＭ
テクニカル・ディスクロージャ・ブルテン，Vol.24,No.
1,１９８１年１１月は、共通の共用メモリを使用する多
重処理システム用のロック方式を開示している。

【００１１】

【発明が解決しようとする課題】本発明の目的は、プロ
セスを実行し、所定の事象の発生時に割込み信号を供給
するための、データ処理システムを提供することであ
る。

【００１２】

【課題を解決するための手段】割込み信号を受け取り、
割込み信号の発生を示すデータを提供する能力を備え
た、割込みマネジャが提供される。また、割込みマネジ
ャは、所定の判断基準に従ってデータを評価し、プロセ
スに事象信号を送るべきか否かを決定する能力を提供す
る。最後に、評価手段によって指示された場合に限って
事象信号を供給する能力をも備える。

【００１３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００２７】

【表１】GRAPHICS_SYSTEM_CALL(Device, Command, Dat
a) Device＝特定の表示装置を示す Command＝実行すべき特定の機能 （たとえば、MAKE_GP、CREATE_RCXなど。） Data＝機能特有のデータ構造 （たとえば、CREATE_RCXの場合、この構造は、以下のフ
ィールドを有する。） エラー・コード、装置上のドメイン番号、 装置特有のデータ構造を指すポインタ、 装置特有のデータ構造の長さ、 作成される抽出コンテキストの識別子 （後続のGRAPHICS_SYSTEM_CALLの呼出しで、RCXを参照
するのに用いる）図４は、ＲＣＭデータ記憶域４４を示
す図である。ＲＣＭ 共通ブロック５０は、ＲＣＭデー
タ記憶域４４に格納されたＲＣＭデータ構造の中心点で
ある。ＲＣＭ共通ブロック５０は、共通プロセス・ブロ
ック（５２や５４など）のリンク・リストの先頭と、装
置ブロック（５６や５８など）のリンク・リストの先頭
を含む。オペレーティング・システムは、ハンドラがＲ
ＣＭデータ構造へのアクセス権を得るための手段を提供
する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７２】

【発明の効果】プロセスを実行し、所定の事象の発生時
に割り込み信号を供給するための、データ処理システム
が提供される。割込み信号を受け取り、割込み信号の発
生を示すデータを提供する能力を備えた、割込みマネジ
ャが提供される。またこの割込みマネジャは、所定の判
断基準に従ってデータを評価し、プロセスに事象信号を
送るべきか否かを決定する能力を提供する。最後に、評
価手段によって指示された場合に限って事象信号を供給
する能力を備える。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２７】レンダリング・コンテキスト切替えモジュー
ルの流れ図である。

【図２８】レンダリング・コンテキスト切替えモジュー
ルの流れ図である。

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

Claims (11)

【特許請求の範囲】
1. 【請求項１】プロセスを実行し、該プロセスの制御のも
   とで装置に関連する所定の事象の発生時に割込み信号を
   発生するデータ処理システムにおける割込みマネジャで
   あって、 割込み信号を受取り該割込み信号から該割込み信号が事
   象とみなされるか否かを指示する割込み事象データを抽
   出する抽出手段と、 前記割込み事象データがプロセスに供給されるべきか否
   かを判定するための所定の基準をプロセスから受取り記
   憶する記憶手段と、 前記抽出手段により抽出された割込み事象データを解釈
   し、前記所定の基準に基づいて前記割込み事象データが
   プロセスに供給されるべきか否かを前記解釈に基づいて
   判断する解釈手段と、 前記割込み信号の全てを受取り順に順次処理し前記解釈
   手段により前記割込み事象データがプロセスに供給され
   るべきと判断された場合にのみ前記割込み事象データを
   プロセスに供給する割込み処理手段と、 を含む割込みマネジャ。
2. 【請求項２】前記抽出手段に接続され以前に受信した割
   込み信号の履歴を記憶するバッファ手段を更に有する、
   請求項１の割込みマネジャ。
3. 【請求項３】前記バッファ手段に接続され、前記バッフ
   ァ手段の内容をプロセスに選択的に転送する転送手段を
   更に有する、請求項２の割込みマネジャ。
4. 【請求項４】前記バッファ手段が満杯になったとき前記
   バッファ手段の内容をプロセスに転送する手段を更に有
   する請求項３の割込みマネジャ。
5. 【請求項５】前記抽出手段に接続され、最後の割込み信
   号を記憶する第２バッファ手段を更に有する請求項４の
   割込みマネジャ。
6. 【請求項６】前記所定の基準がプロセスの現在の状態を
   表す状態情報を含む請求項１の割込みマネジャ。
7. 【請求項７】プロセスを実行し、該プロセスの制御のも
   とで装置に関連する所定の事象の発生時に割込み信号を
   発生するデータ処置システムにおいて割込み信号を処理
   する方法であって、 割込み信号を受取り該割込み信号から該割込み信号が事
   象とみなされるか否かを指示する割込み事象データを抽
   出する段階と、 前記割込み事象データがプロセスに供給されるべきか否
   かを判定するための所定の基準をプロセスから受取り記
   憶する段階と、 抽出された割込み事象データを解釈し、前記所定の基準
   に基づいて前記割込み事象データがプロセスに供給され
   るべきか否かを前記解釈に基づいて判断する段階と、 前記割込み信号の全てを受取り順に順次処理し前記割込
   み事象データがプロセスに供給されるべきと判断された
   場合にのみ前記割込み事象データをプロセスに供給する
   段階と、 を含む割込み処理方法。
8. 【請求項８】以前に受信した割込み信号の履歴をバッフ
   ァに記憶する段階を更に有する、請求項７の割込み処理
   方法。
9. 【請求項９】前記バッファに記憶された内容をプロセス
   に選択的に転送する転送する段階を更に有する、請求項
   ８の割込み処理方法。
10. 【請求項１０】前記バッファが満杯になったとき前記バ
    ッファの内容をプロセスに転送する段階を更に有する請
    求項９の割込み処理方法。
11. 【請求項１１】最後の割込み信号を第２バッファに記憶
    する段階を更に有する請求項１０の割込み処理方法。