(57)【要約】  コンピュータ装置用のオペレーティング・システムは、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むスケジューラを含む。オペレーティング・システムは、優先度で順序づけられた、装置上で稼動するようにスケジュールされるスレッドのリストを提供するようにも構成される。ロック機構を保持するスレッドを除く全スレッドからの、装置の資源へのアクセスを阻止する少なくとも１つのロック機構も提供され、オペレーティング・システムは、要求する資源がロックされているために稼動することをドッキングされる、スケジュールされたスレッドに、ロック機構を保持するスレッドを稼動させるように調整する。
2007537504.tif 000002
【特許請求の範囲】
【請求項１】
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、当該装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを有する、スケジューラを備え、
ロック機構を保持するスレッドを除く全てのスレッドからの、当該装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構をさらに備え、
稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させる
ことを特徴とするコンピュータ装置。
【請求項２】
スレッドに状態が割り当てられ、
前記リストは、共通の状態を有する全スレッドを備える
ことを特徴とする請求項１に記載のコンピュータ装置。
【請求項３】
阻止されたスレッドは、その状態を変更することが許可されていない
ことを特徴とする請求項２に記載のコンピュータ装置。
【請求項４】
前記リストは、それが有する前記スレッドの前記優先度に基づいて細分される
ことを特徴とする請求項１から３のいずれか１項に記載のコンピュータ装置。
【請求項５】
スレッドは、それがその上で阻止されるあらゆるロック機構へのポインタを有するように構成される
ことを特徴とする請求項１から４のいずれか１項に記載のコンピュータ装置。
【請求項６】
ネスト不可能な複数のロック機構を備えることを特徴とする請求項１から５のいずれか１項に記載のコンピュータ装置。
【請求項７】
前記スケジューラは、当該コンピュータ装置上で稼動させられる割込みサービス・ルーチンの最後でコールされるように構成される
ことを特徴とする請求項１から６のいずれか１項に記載のコンピュータ装置。
【請求項８】
前記ロック機構は、ミューテックスが解放されている場合はヌルであるポインタ、又は、前記ミューテックスを保持する前記スレッドを指すポインタを有する、ミューテックスを備え、
前記ミューテックスへの競合が存在するかどうかを示すフラグを有する
ことを特徴とする請求項１から７のいずれか１項に記載のコンピュータ装置。
【請求項９】
前記アルゴリズムは、当該コンピュータ装置の構成に依存して構成された置換え可能なメモリ・モデルに、メモリ管理を委ねるように構成される
ことを特徴とする請求項８に記載のコンピュータ装置。
【請求項１０】
前記メモリ・モデルは、プリエンプティブル・モード、又は、非プリエンプティブル・モードで稼動するように構成される
ことを特徴とする請求項９に記載のコンピュータ装置。
【請求項１１】
ミューテックスは、前記モジュールを、前記プリエンプティブル・モードで稼動しないよう保護するように構成される
ことを特徴とする請求項１０に記載のコンピュータ装置。
【請求項１２】
前記スケジューラは、前記コンピュータ装置のオペレーティング・システムのカーネル中に存在する
ことを特徴とする請求項１から１１のいずれか１項に記載のコンピュータ装置。
【請求項１３】
前記カーネルは、マイクロカーネル又はナノカーネルを備え、
前記スレッドは、それぞれ、マイクロカーネル・スレッド又はナノカーネル・スレッドである
ことを特徴とする請求項１２に記載のコンピュータ装置。
【請求項１４】
前記スケジューラは、前記カーネルがロック解除される度にコールされるように構成される
ことを特徴とする請求項１２または１３に記載のコンピュータ装置。
【請求項１５】
移動コンピュータ装置を備えることを特徴とする請求項１から１４のいずれか１項に記載のコンピュータ装置。
【請求項１６】
スマート・フォンを備えることを特徴とする請求項１５に記載のコンピュータ装置。
【請求項１７】
コンピュータ装置を制御する方法であって、
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを有する、スケジューラを提供する工程と、
ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構を提供する工程と、
稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させるように調整する工程と、
を備えることを特徴とする方法。
【請求項１８】
コンピュータ装置用のオペレーティング・システムであって、
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを提供する手段を有する、スケジューラと、
ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構と、
前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させるように調整する手段と、
を備えることを特徴とするオペレーティング・システム。
【請求項１９】
スレッドに状態が割り当てられ、
前記リストは、共通の状態を有する全スレッドを備える
ことを特徴とする請求項１８に記載のオペレーティング・システム。
【請求項２０】
阻止されたスレッドは、その状態を変更することが禁止されているように構成される
ことを特徴とする請求項１９に記載のオペレーティング・システム。
【請求項２１】
前記リストは、それが有する前記スレッドの前記優先度に基づいて細分されるように構成される
ことを特徴とする請求項１８から２０のいずれか１項に記載のオペレーティング・システム。
【請求項２２】
スレッドは、それがその上で阻止されるあらゆるロック機構へのポインタを有するように構成される
ことを特徴とする請求項１８から２１のいずれか１項に記載のオペレーティング・システム。
【請求項２３】
ネスト不可能な複数のロック機構を備えることを特徴とする請求項１８から２２のいずれか１項に記載のオペレーティング・システム。
【請求項２４】
前記スケジューラは、前記コンピュータ装置上で稼動させられる割込みサービス・ルーチンの最後でコールされるように構成される
ことを特徴とする請求項１８から２３のいずれか１項に記載のオペレーティング・システム。
【請求項２５】
前記ロック機構は、ミューテックスが解放されている場合はヌルであるポインタ、又は、前記ミューテックスを保持する前記スレッドを指すポインタを有する、ミューテックスを備え、
前記ミューテックスへの競合が存在するかどうかを示すフラグを有する
ことを特徴とする請求項１８から２４のいずれか１項に記載のオペレーティング・システム。
【請求項２６】
前記アルゴリズムは、前記コンピュータ装置の構成に依存して構成された置換え可能なメモリ・モデルに、メモリ管理を委ねるように構成される
ことを特徴とする請求項２５に記載のオペレーティング・システム。
【請求項２７】
前記メモリ・モデルは、プリエンプティブル・モード、又は、非プリエンプティブル・モードで稼動するように構成される
ことを特徴とする請求項２６に記載のオペレーティング・システム。
【請求項２８】
ミューテックスは、前記モジュールを、前記プリエンプティブル・モードで稼動しないよう保護するように構成される
ことを特徴とする請求項２７に記載のオペレーティング・システム。
【請求項２９】
前記スケジューラは前記カーネル中に存在することを特徴とする請求項１８から２８のいずれか１項に記載のオペレーティング・システム。
【請求項３０】
前記カーネルは、マイクロカーネル又はナノカーネルを備え、
前記スレッドは、それぞれ、マイクロカーネル・スレッド又はナノカーネル・スレッドである
ことを特徴とする請求項２９に記載のオペレーティング・システム。
【請求項３１】
前記スケジューラは、前記カーネルがロック解除される度にコールされるように構成される
ことを特徴とする請求項２９または３０に記載のオペレーティング・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ装置用のオペレーティング・システムに関し、特に、信頼性および性能に関して大きな利点をもたらす、コンピュータ装置のオペレーティング・システム・カーネル用の相互排他機構を提供する方法に関する。
【背景技術】
【０００２】
本明細書で使用するコンピュータ装置という用語は、拡張的には、どのような形態の電気装置にも当てはまることが企図されるものであり、どのような形状因子のデジタル静止画および動画カメラなどのデータ記録装置も、ハンド・ヘルドおよびパーソナル・コンピュータを含むどのタイプまたは形のコンピュータも、１台の装置内で通信、画像の記録および再生の少なくともいずれか、ならびに計算機能を併用する携帯電話、スマート・フォン、発信機を含むどの形状因子の通信装置も、ならびに他の形態の無線および有線情報装置も含む。
【０００３】
ほとんどのコンピュータ装置は、オペレーティング・システム（ＯＳ）の制御下で動作するようにプログラミングされる。オペレーティング・システムは、コンピュータ装置の中央処理装置に供給される、コードの形態をした一連の命令を用いて、コンピュータ装置を制御する。こうした命令は、オペレーティング・システムによってスケジュールされる、一連の、実行の準自律的な基本単位とみなすことができる。こうした実行の基本単位は、それぞれ、コンピュータ装置内で実施されるスレッドおよびプロセスとして知られ、常に１つまたは複数のスレッドを含む。一般的なオペレーティング・システムは、コンピュータ装置によって実行される非常に様々なタスクを制御するために、異なる多くのスレッドをスケジュールする。
【０００４】
オペレーティング・システムは、いくつかの構成要素からなるとみなすことができる。こうした構成要素の一部は、コンピュータ装置のハードウェア資源に対して、他の構成要素よりも特権的なアクセス権を有する。より特権的なアクセス権を有する構成要素は、特権的構成要素（privileged components）として知られる。このような特権的構成要素の１つまたは複数は、一般にオペレーティング・システムのカーネルとして知られるものを形成する。
【０００５】
ＯＳカーネルは一般に、オペレーティング・システム自体の他の部分すべてが、プラットフォーム上で稼動する全アプリケーションと共にそれに依存しなければならないコア・サービスを提供する。こうしたコア・サービスを成り立たせるものに関する考え方は、時とともに変化しており、オペレーティング・システムの全体的な設計に対する必然的な影響が、本発明の背景を成り立たせている。
【０００６】
しかし、ＯＳの設計には２つの基本的手法があることが概して認められている。これらはしばしば、「モノリシック・カーネル」手法および「マイクロカーネル」手法と呼ばれる。
【０００７】
モノリシック・カーネルは大きなブロックを構成するコードであり、用意されている最高特権レベルで稼動されるオペレーティング・システム全体の比較的大きな割合を含むものである。このカーネルは通常、コンピューティング・ハードウェアを有するインターフェースをすべて含む。現代のモノリシック・カーネルは、カーネルの設計に実質的なモジュール方式を導入している。この方式は、従来このような設計に関連していた移植性、アップグレード性およびメモリ使用の問題を軽減する、形式インターフェース層と実行時にロード可能なカーネル・モジュールとを有する。しかし、高特権レベルで（カーネル・モードとして知られるモードで）稼動する、本質的な機能を有するコードからなる非常に大きなブロックの主な特徴は、モノリシック・カーネルに基づく主要なすべての商用オペレーティング・システムの内部に保たれている。ただし、このような商用オペレーティング・システムには、マイクロソフト製のＷｉｎｄｏｗｓ（登録商標）およびＬｉｎｕｘのほとんどのバージョンが含まれる。
【０００８】
対照的に、マイクロカーネル手法は、モノリシック・カーネルの手法とは大きく異なる。提供されるオペレーティング・サービスは、最小限にされ、一般に、スケジューリング、同期、およびプロセス間通信と共に、プロセスおよびアドレス空間の完全性の確保にまで削減される。メモリ管理をしばしば含む他の全オペレーティング・システム・サービスが、ロード可能なモジュールとして提供される。しかし、モノリシック・カーネル手法との重大な違いは、こうした他のサービスが、カーネル・メモリ空間にロードされ、次いで、カーネル・モードで実行されるのではなく、それ自体の個々のメモリ空間にロードされ、ユーザ・モードとして知られる低特権レベルで稼動するサーバとして実施されることである。
【０００９】
図１は、上述した２つのアーキテクチャ・パラダイムの間の主要な違いを示す。
【００１０】
初期のマイクロカーネルに基づくオペレーティング・システムは、アカデミックであった（例えば、カーネギーメロン大学で開発されたＭａｃｈカーネル）が、マイクロカーネル設計のミニマリズム（minimalism）および必然的な予測可能性により、１９９０年代半ば以降、そうしたシステムが、リアルタイムの組込みオペレーティング・システムに対する標準になった。Ｗｉｎｄ  Ｒｉｖｅｒ、ＱＮＸ、ＯＳＥおよびＭｅｎｔｏｒ  Ｇｒａｐｈｉｃｓはすべて、そのリアルタイムのオペレーティング・システム（ＲＴＯＳ）において、マイクロカーネル設計の要素を使用する。より最近では、Ｍａｃｈカーネル自体が、ＡｐｐｌｅのＭａｃ  ＯＳ  Ｘの基盤にあるオープンソースのＤａｒｗｉｎ  ＸＮＵカーネルに統合されており、Ｍａｃｈも、標準のモノリシックＵｎｉｘ（登録商標）／Ｌｉｎｕｘカーネルの代用としてＧｎｕプロジェクトが開発したＨｕｒｄカーネルの基礎である。
【００１１】
その決定論的特性と同様に、マイクロカーネル・アーキテクチャは、モノリシック・カーネルに勝る、柔軟性、拡張性、安全性、および信頼性における利点ももたらし得る。
【００１２】
しかし、欠点もある。マイクロカーネルは、モノリシック・カーネルでは同じアドレス空間を共有し、互いのアプリケーション・プログラム・インターフェース（ＡＰＩ）を直接呼び出すことができていたユーザ・モード・プロセスの間の全通信を仲介しなければならないので、コンテキスト切換えの頻度が非常に高くなる。これにより、ホスト・システムのハードウェアおよびメモリ・アーキテクチャによっては、モノリシック・カーネルと比較すると、性能がより低下する可能性がある。
【００１３】
マイクロカーネル設計の開発に用いられている技術を、最低レベルのマイクロカーネル自体に拡大することが可能である。これは実際に行われており、いわゆるナノカーネル・アーキテクチャの基礎である。おそらく、ナノカーネルは、高度にミニマリズムなマイクロカーネルに過ぎないので、ＯＳ設計手法における新たな発展を示していない。実際、マイクロカーネルの最小化に関する学術文献はほとんど、ナノカーネルの設計に十分に応用可能である。例えば、論文（非特許文献１）のセクション２を参照されたい。
【００１４】
しかし、マイクロカーネルが原始的になると、オペレーティング・システムの不可欠な部分としてのその役割が小さくなる。というのは、ナノカーネル上ですべて実施することができる、オペレーティング・システムの別個の様々な個性を稼動することが可能になるからである。この開発の可能性は、マイクロカーネルの開発において、早くから認められていた。例えば、非特許文献２を参照されたい。ここには、いくつかのオペレーティング・システムの多様なインスタンス化を単一のハードウェア・システム上で稼動するための能力を要件として含んでいるナノカーネルについて記述されている。
【００１５】
この可能性は、理論的なだけではない。すなわち、Ｊｏｃｈｅｎ  ＬｉｅｄｔｋｅのＬ４マイクロカーネルのバージョンは、他のタスクと共にＬｉｎｕｘを稼動することができる。例えば、Ｆｉａｓｃｏとして知られ、Ｌ４マイクロカーネルと互換性がある、ｘ８６およびＡＲＭプラットフォーム上で稼動する、リアルタイム性能を有するマイクロカーネルは、Ｌ４Ｌｉｎｕｘ上で稼動することが実証されている。Ｌ４Ｌｉｎｕｘは、ＤＯｐＥリアルタイム・ウィンドウ環境がマイクロカーネルの上で稼動し、Ｌ４Ｌｉｎｕｘのインスタンスがウィンドウの１つで稼動している、ユーザ・モードで完全に実行するＬ４インターフェースへのＬｉｎｕｘカーネルの移植である。
【００１６】
しかし、現在の技術には欠陥がある。マイクロカーネルがオペレーティング・システム全体を支えていることにより、堅牢性を備えるとともに効率的な設計が非常に重要になる。具体的には、スケジューリング・プロセスおよびタスクにおけるマイクロカーネルの役割は、オペレーティング・システムを全体として機能させるのに決定的に重要であり、失敗することは決して許されない。このようなスケジューリングは、特にリアルタイムのオペレーティング・システム（ＲＴＯＳ：real-time operating system）が関わる場合は、些細なことではない。ＲＴＯＳは、特定のイベントへの応答時間について確かな保証を行うことができなければならない。ＲＴＯＳがこのような保証を行うのを可能にする主要機構の１つは、特定のタスクを、リアルタイムへの重要度の順序でランクづけし、最も重要なタスクを、より重要でないものに先んじてスケジュールする優先度機構（priority mechanism）である。
【００１７】
マルチタスク・オペレーティング・システムにおける優先度機構に伴う公知の問題は、優先度が逆転するという現象である。これは、優先度の低いタスクが、優先度の高いタスクによって必要とされる資源に対するロック（相互排他オブジェクト、すなわちミューテックスとして知られる）を保持するというものである。この状況を予期するためのステップがとられない限り、タスク・スケジューリング・アルゴリズムは常に、より優先度が高いタスクを、より低い優先度のものに先んじて稼動しようとし、資源ロックが決して解放されることがなく、したがって、より優先度が高いタスクが阻止されるようになるという結果をもたらす。
【００１８】
優先度の逆転の問題に対する解決策は、優先度の継承であり、これは、資源に対するロックをもつタスクの優先度が、その資源を待っている最高優先度のタスクのレベルまたはそれ以上のレベルまで、常に高められることを意味する。ただし、優先度の継承の従来の方法は、実施するための計算コストが高く、したがって、オペレーティング・システムの設計者に、性能に対して堅牢性を相殺することを強制する可能性がある。
【００１９】
公知の少なくとも１つのケースである、１９９７年の火星探査機マーズ・パスファインダの任務において、性能上の理由で、優先度の継承を使わないという決定がなされた。非特許文献３の中で、Ｔｏｍ  Ｄｕｒｋｉｎは、次のように書いている。
【００２０】
「通信の衝突を防止するために、ＶｘＷｏｒｋｓが、バスへのアクセスを相互排他ソフトウェア・ロックと同期させた。しかし、非常にまれにではあるが、優先度の高いスレッドが、優先度の低い気象データ・スレッドが稼動するのを待つ間に阻止された瞬間に、優先度が中程度の通信タスクをスケジュールさせた割込みがバスに送信された。長時間稼動する、優先度が中程度のこの通信タスクは、優先度の低い気象タスクより高い優先度を有し、気象タスクが稼動するのを防止することになった。このシナリオは、優先度の逆転の古典的なケースである。Ｗｉｎｄ  Ｒｉｖｅｒは、ＶｘＷｏｒｋｓの性能の最適化を開始する前に、優先度の継承という選択肢を次第に失わせた」。
【００２１】
現在の多くのマイクロカーネル設計の欠陥は、別個の、計算コストが高い優先度の継承機構を特徴とすることである。したがって、こうした機構を停止させて、オペレーティング・システムの性能を高めたいという衝動が常に起こる。したがって、性能を何ら損なうことなく、自動的な優先度の継承を提供するアーキテクチャは、堅牢性および性能が互いに対して相殺されることを強制することがないので、既存の設計よりも好ましい。このことは、１つまたは複数のオペレーティング・システムを運用するのに、ナノカーネルが使われる場合に特に当てはまる。というのは、ナノカーネルにおけるいかなる不信頼度も、そのまま、総じてオペレーティング・システムにおける不信頼度につながるからである。
【非特許文献１】Ｊｏｃｈｅｎ  Ｌｉｅｄｔｋｅ、「μ−カーネルの構築について（Ｏｎ  μ−Ｋｅｒｎｅｌ  Ｃｏｎｓｔｒｕｃｔｉｏｎ）」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  １５ｔｈ  ＡＣＭ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｐｒｉｎｃｉｐｌｅｓ、１９９５年１２月
【非特許文献２】Ｂｏｍｂｅｒｇｅｒら、「ＫｅｙＫＯＳナノカーネル・アーキテクチャ（Ｔｈｅ  ＫｅｙＫＯＳ  Ｎａｎｏｋｅｒｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ＵＳＥＮＩＸ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｍｉｃｒｏ−Ｋｅｒｎｅｌｓ  ａｎｄ  Ｏｔｈｅｒ  Ｋｅｒｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ、ＵＳＥＮＩＸ  Ａｓｓｏｃｉａｔｉｏｎ、１９９２年４月
【非特許文献３】Ｔｏｍ  Ｄｕｒｋｉｎ、「Ｗｈａｔ  ｔｈｅ  Ｍｅｄｉａ  Ｃｏｕｌｄｎ’ｔ  Ｔｅｌｌ  Ｙｏｕ  Ａｂｏｕｔ  ＭａｒｓＰａｔｈｆｉｎｄｅｒ」Ｒｏｂｏｔ  Ｓｃｉｅｎｃｅ＆Ｔｅｃｈｎｏｌｏｇｙ  Ｉｓｓｕｅ  １、１９９８年
【発明の開示】
【発明が解決しようとする課題】
【００２２】
したがって、本発明の目的は、いかなる性能も損なうことなく、自動的な優先度の継承を示すことができる改良されたコンピュータ装置を提供することである。
【課題を解決するための手段】
【００２３】
本発明の第１の態様によると、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、当該装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを有する、スケジューラを備え、ロック機構を保持するスレッドを除く全てのスレッドからの、当該装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構をさらに備え、稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させることを特徴とするコンピュータ装置が提供される。
【００２４】
本発明の第２の態様によると、コンピュータ装置を制御する方法であって、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを有する、スケジューラを提供する工程と、ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構を提供する工程と、稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させるように調整する工程と、を備えることを特徴とする方法が提供される。
【００２５】
本発明の第３の態様によると、コンピュータ装置用のオペレーティング・システムであって、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドのリストを提供する手段を有する、スケジューラと、ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構と、前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記ロック機構を保持する前記スレッドを稼動させるように調整する手段と、を備えることを特徴とするオペレーティング・システムが提供される。
【発明を実施するための最良の形態】
【００２６】
次に、本発明の実施形態を、モノリシックなマイクロカーネル・アーキテクチャの例を示す添付の図面を参照して、さらに例示としてのみ説明する。
【００２７】
本発明について、英国ロンドンのＳｙｍｂｉａｎ  Ｌｉｍｉｔｅｄから販売されているＳｙｍｂｉａｎ  ＯＳ（商標）オペレーティング・システムを具体的に参照して説明するが、本発明の原理を、他の形のオペレーティング・システムにおいて用いても、同様の利点を得ることができることを理解されたい。
【００２８】
Ｓｙｍｂｉａｎ  ＯＳオペレーティング・システムは、ハード・リアルタイムのサポートを提供するプリエンプティブなマルチスレッドのナノカーネル・スタイル層を含む。「高速ミューテックス」と呼ばれる単一の機構の実施が見られるのは、このナノカーネル内部である。このことは、カーネル・スレッドが資源に対して相互排他ロックを提供する方法の利益と、ミューテックスを保持するタスクの自動的な優先度の継承の方法の利益とを併せもつ。カーネルは、そのマルチスレッド性により、シングルプロセッサの、または対称多重処理（ＳＭＰ：symmetrical multiprocessing）システムにおける使用に適し、高速ミューテックスは、いずれの構成においても用いることができる。
【００２９】
本発明を十分に理解させるために、Ｓｙｍｂｉａｎ  ＯＳオペレーティング・システム全体を記載することが必要とは考えられない。したがって、以下では、本発明に関連するオペレーティング・システムの部分に限定して説明を行う。Ｓｙｍｂｉａｎ  ＯＳカーネルは、図１に示すモノリシックな手法とマイクロカーネル手法の間の混成であり、したがって、両方のある種の利点を併せもつ。ユーザ側サーバの利益のためにメッセージ引渡しフレームワークを実施するカーネルの概念は、マイクロカーネル・アーキテクチャから引き出される。そのネットワークおよびテレフォニー・スタック、ならびにファイル・システムは、すべてユーザ側サーバである。一方、ロード可能なカーネル・モジュールとしてのデバイス・ドライバの実施は、モノリシック・カーネル・アーキテクチャから派生する。
【００３０】
ナノカーネル自体は、メモリの管理についてはほとんど知らない。他の多くのマイクロカーネルおよびナノカーネル・アーキテクチャのように、ナノカーネルは、このタスクを外部のモジュールに委任する。これは、メモリ・モデルと呼ばれる。カーネルは、メモリ・モデルに、スケジュール変更に合わせてアドレス空間切換えを実施させるフック（hook）を提供する。
【００３１】
様々なメモリ・モデルが、Ｓｙｍｂｉａｎ  ＯＳオペレーティング・システムにおいて実施されている。このうちの２つに、特に注目すべきである。
・移動メモリ・モデルは、単一のページ・ディレクトリを使い、ディレクトリ内のエントリは、各プロセス間コンテキスト切換えの際に移動される。この移動は、比較的長時間に渡る動作である可能性があり、したがって、ナノカーネルのメモリ・フック機能は、このモデルにおいて有効にされた特権をもって稼動する。こうすることにより、プロセス切換えがスレッドの待ち時間に悪影響を与えることが妨げられる。
・多様なメモリ・モデルにおいて、各プロセスは、それ自体のページ・ディレクトリを有し、コンテキスト切換えは、ページ・ディレクトリ・ベース・レジスタを変更する。このモデルにおいて、アドレス空間変更は、ページ・ディレクトリの変更のみを伴うので、高速である。したがって、ナノカーネルのメモリ・フック機能は、効率を上げコードを簡素化するために、特権を無効にされて稼動する。
【００３２】
ナノカーネルはマルチスレッドであり、その主要な機能の１つは、使用可能な中央演算装置（ＣＰＵ）資源を、いくつかのスレッドの間で共有することである。
【００３３】
ナノカーネル・スレッドは、他のほとんどのＲＴＯＳにおいて見られるスレッドに類似しており、その本質的な特性は、各々が、それ自体のスタックを、０と６３を含むその間の整数である優先度と共に有することである。スレッドは、異なるいくつかの状態にあり得る。ＲＥＡＤＹ状態にある全スレッドは、実行に適格であり、「実行可能リスト（ready list）」と呼ばれるものにリンクされる。スレッドは通常、優先度に基づいてスケジュールされ、オペレーティング・システム内部のスケジューラは、実行可能リストにある、優先度が最高のスレッドが稼動するように制御する。
【００３４】
実行可能リストは常に、カーネルがロックされてアクセスされるので、スレッド遅延を低く保つために、実行可能リストに対する全操作が抑制され、可能な限り高速であることが必要とされる。これは、６４個の別々のキューを使うことによって遂行され、１つのキューが、各スレッドの可能な優先度用であり、６４個のスレッドの優先度に対する制約を記述する。実行可能リストにある各スレッドは、その優先度に対応するキューの中に配置される。６４ビット・マスクも、どのキューが空でないかを示すように維持される。マスク中のビットｎは、優先度ｎ用のキューが空でないとき、かつそのときに限りセットされる。
【００３５】
実行可能リストにエントリを挿入するために必要なことは、その優先度に対応するキューの末尾にエントリを追加し（探索は必要とされない）、ビット・マスク中の対応するビットをセットすることだけである。エントリを削除するには、最初にそのキューにあるリンクがオープンされる。次いで、そのキューが空の場合、ビット・マスク中のそれぞれのビットがリセットされる。優先度が最も高いエントリをみつけるためには、ビット・マスク中の最上位の１が発見され（これは、バイナリ・サーチを用いても、一部のＣＰＵに対する単一の命令によっても行うことができる）、次いで、対応するキューにある第１のエントリが発見される。
【００３６】
この実施はしたがって、エントリの挿入および削除のために、かつ優先度が最も高いエントリをみつけるために、制限された（かつ短い）実行時間をもたらす。メモリを節約するために、各キューに対して単一のポインタが使われる。このポインタは、キューが空の場合はＮＵＬＬであり、空でない場合は、キューにある第１のエントリを指す。キューにあるエントリは、二重リンクされたリングに構成される。
【００３７】
ナノカーネルは、スレッド切換えが必要とされる可能性があるかどうかを示すフラグ（ｉＲｅｓｃｈｅｄｕｌｅＮｅｅｄｅｄＦｌａｇ）を維持する。このフラグは、既にリストにある他のどのスレッドの最高優先度よりも優先度が高い又は等しいスレッドが、実行可能リストに追加されたときは、常に、あるいは、同等のケースにおいては、同じ優先度である第１のスレッドが、そのタイムスライスを使っているときにセットされる（各スレッドは、指定されたタイムスライスを有する）。このフラグも、現在のスレッドのタイムスライスが満了すると、ナノカーネル・タイマ・ティック割込みによってセットされる。続いて、カーネルがロック解除されると、このフラグは、スケジュール変更が必要とされるかどうか判定するために調べられる。フラグは、スケジュール変更が実際に起こるとクリアされる。
【００３８】
各スレッドは、指定されたタイムスライス（ｉＴｉｍｅｓｌｉｃｅ）および時間カウント（ｉＴｉｍｅ）を有する。スレッドが阻止し、または同じ優先度のスレッドのキューの最後に循環される度に、ｉＴｉｍｅフィールドは、ｉＴｉｍｅｓｌｉｃｅに等しく設定される。低レベルのティック割込みは、現在のスレッドのｉＴｉｍｅが正の場合はそれを減分し、ゼロになると、スケジュール変更をトリガする。したがって、ｉＴｉｍｅｓｌｉｃｅが正の場合、スレッドは、同じ優先度である次のスレッドに移る前に、ｉＴｉｍｅｓｌｉｃｅの低レベル・タイマ・ティック向けに稼動する。ｉＴｉｍｅｓｌｉｃｅが負の場合、スレッドは、阻止する場合は同じ優先度の他のスレッドに移るだけである。
【００３９】
各スレッドは、カーネル・コードのクリティカル・セクションにスレッドが毎回入る度に増分されるクリティカル・セクション・カウント（ｉＣｓＣｏｕｎｔ）を有し、クリティカル・セクションの間、スレッドは、中断することも強制終了することもできない。別のスレッドを中断し、または強制終了しようとするスレッドは、最初に目標スレッドのクリティカル・セクション・カウントを調べなければならない。カウントがゼロの場合、スレッドは、直ちに中断しても、強制終了してもよい。カウントがゼロでない場合、スレッドが、クリティカル・セクションを退去するときに中断し、または退出するべきかどうかを示すように、別のフラグがセットされる（ｉＣｓＦｕｎｃｔｉｏｎ）。スレッドが、カーネル・コードのクリティカル・セクションを退去するとき、そのｉＣｓＣｏｕｎｔは減分され、ゼロになると、ｉＣｓＦｕｎｃｔｉｏｎが調べられ、スレッドは、必要に応じてそれ自体を中断し、または退出する。他のスレッドのＳｕｓｐｅｎｄ（）またはＫｉｌｌ（）を呼び出したスレッドは、どの段階でも阻止されず、単に実行を続ける。
【００４０】
高速ミューテックスが、ナノカーネル・スレッドの間の相互排他を可能にする基本的な手段として提供される。高速ミューテックスは、以下の特性を有する。
・ロックを巡る競合がない場合は非常に高速である。
・低ＲＡＭフットプリント。
・スレッドは、何らかの高速ミューテックス（ネスト不可能である）を既に保持している場合、高速ミューテックスを待たなくてよい。
・スレッドは、高速ミューテックスを保持している間、退出することも、ナノカーネルの外の層で実施されるオブジェクトを待つこともできない。
【００４１】
本発明において、上述したスレッド・クリティカル・セクション・システムは、スレッドが、高速ミューテックスを保持する間、終了されないことを確実にするように拡張される。すなわち、高速ミューテックスを保持するスレッドは、クリティカル・セクションにあるものとして扱われるので、スレッドの外部中断および終了は、スレッドが高速ミューテックスを解放するまで延期される。これは、スレッドが、例えば、例外をとった結果として、高速ミューテックスを保持している間にそれ自体を退出しようと試みるケースについては扱わない。クリティカル・セクションにある間に退出しようと試みるスレッドと同様に、これは、カーネルに障害を起こす。
【００４２】
高速ミューテックスの保持は、１つのスレッドが、同じ優先度の複数のスレッドに時間分割されるのも妨げる。これは、短いクリティカル・セクション中に、スレッドの間の切換えに不必要に費やされる時間を削減するために行われる。高速ミューテックスは本質的に、コードの短いクリティカル・セクションを効率的に保護するように設計される。
【００４３】
高速ミューテックスは、保持スレッドへのポインタ（ミューテックスが解放されている場合はＮＵＬＬであるｉＨｏｌｄｉｎｇＴｈｒｅａｄ）と、ミューテックスに対する競合が起こっていること、またはミューテックスが保持されたせいで、例えば、保持スレッドの中断、終了またはラウンドロビンというアクションが延期されていることを示すフラグ（ｉＷａｉｔｉｎｇ）とからなる。さらに、各ナノカーネル・スレッドは、高速ミューテックスがネストしないので最大１つが存在し得る、スレッドによって現在保持されている高速ミューテックスへのポインタ（何も保持されていない場合はＮＵＬＬであるｉＨｅｌｄＦａｓｔＭｕｔｅｘ）をもつ。各ナノカーネル・スレッドは、そのスレッドが現在その上で阻止されている高速ミューテックスへのポインタ（何も阻止されていない場合はＮＵＬＬであるｉＷａｉｔＦａｓｔＭｕｔｅｘ）も有する。
【００４４】
高速ミューテックスにおいて待機するアルゴリズムは、以下のようになり得る。
カーネルをロックする
ＩＦ（ｉＨｏｌｄｉｎｇＴｈｒｅａｄ！＝ＮＵＬＬ）
ｉＷａｉｔｉｎｇ＝ＴＲＵＥ
現在のスレッド→ｉＷａｉｔＦａｓｔＭｕｔｅｘ＝ｔｈｉｓ
ｉＨｏｌｄｉｎｇＴｈｒｅａｄに移る
カーネルをロックする
割込みを再度可能にする
現在のスレッド→ｉＷａｉｔＦａｓｔＭｕｔｅｘ＝ＮＵＬＬ
ＥＮＤＩＦ
現在のスレッド→ｉＨｅｌｄＦａｓｔＭｕｔｅｘ＝ｔｈｉｓ
ｉＨｏｌｄｉｎｇＴｈｒｅａｄ＝現在のスレッド
カーネルをロック解除する。
【００４５】
競合がないケースでは、このアルゴリズムは、単に２つの変数割当てにまで減ずる。非ＳＭＰ（非対称処理：non symmetrical processing）システム上では、このアルゴリズムは、ｉＨｏｌｄｉｎｇＴｈｒｅａｄを調べる間、カーネルをロックするのではなく、割込みを単に不可能にすることによって、さらに最適化することができ、かつそのように最適化されている。
【００４６】
本発明は、自動的な優先度の継承を実現する。このことは、高速ミューテックスにおいて阻止されるスレッドが、実行可能リストから削除されないことを意味する。これは、このようなスレッドを実行可能リストから常に削除し、阻止された別個のリストでキューに入れる他のオペレーティング・システムおよびスケジューリング・アルゴリズムとは、明らかに対照的である。（Ｓｙｍｂｉａｎ  ＯＳナノカーネルでは、このような阻止された状態があるが、ナノカーネルの上のＯＳ層内で実施される待ちオブジェクト上で阻止されるスレッドに対して用いられるだけである）。
【００４７】
実行可能リストから削除されるのではなく、高速ミューテックスにおいて阻止されるスレッドは、「ｉＨｏｌｄｉｎｇＴｈｒｅａｄに移る」操作を実行する。この操作は、現在のスレッドから、スレッドを保持しているミューテックスへの直接コンテキスト切換えを実施する。この切換えは、実行可能リストから、どのスレッドも削除せず、長時間稼動するメモリ管理ユニット（ＭＭＵ）ページ・テーブルのどの取り扱いも実施しない。つまり、移動メモリ・モデルと共に使われる場合、この切換えは、高速ミューテックスにおいてスレッドを阻止することによって被るオーバーヘッドを削減するために、（遅い）プロセス・コンテキスト切換えを可能にするためのナノカーネル・フックを呼び出さない。ただし、この操作は、アドレス空間変更は非常に高速なので、多様なメモリ・モデルに対してアドレス空間変更を確かに実施する。
【００４８】
このことは、現在のスレッドが高速ミューテックスを保持する間、ユーザ・アドレス空間が、永続的であることを保証されないことを意味する。これに対する唯一の例外は、保持される高速ミューテックスが、移動メモリ・モデルにおいて、メモリ・フック機能がネストしないようにするのに使われる「システム・ロック」であるときである。ＹｉｅｌｄＴｏは、後で説明するが、スケジューラ自体がそうであるように、割込みが不可能にされ、カーネルがロック解除されて戻ることに留意されたい。スケジューリング・アルゴリズムは、ミューテックスが解放されるまでＹｉｅｌｄＴｏが戻らないようにすることにも留意されたい。
【００４９】
実行可能リストからスレッドを削除せず、代わりにスレッドを保持しているミューテックスに直ちに移ることによって、優先度の継承が効果的に実現される。この継承は、高速ミューテックスにおいて阻止されるスレッドが、実行可能リスト上に留まり、そうすることによって、優先度が最も高い阻止されたスレッドと少なくとも同程度に優先度が高い別のスレッドが使用可能になった場合にのみトリガすることができるので、スケジュール変更が発生する。したがって、保持スレッドは効果的に、その優先度を、優先度が最も高い阻止されたスレッドの優先度まで上げさせる。
【００５０】
高速ミューテックスを解放する一般的なアルゴリズムは、以下のようになる。
カーネルをロックする
ｉＨｏｌｄｉｎｇＴｈｒｅａｄ＝ＮＵＬＬ
現在のスレッド→ｉＨｅｌｄＦａｓｔＭｕｔｅｘ＝ＮＵＬＬ
ＩＦ  ｉＷａｉｔｉｎｇ
ｉＷａｉｔｉｎｇ＝ＦＡＬＳＥ
ＴｈｅＳｃｈｅｄｕｌｅｒ．ｉＲｅｓｃｈｅｄｕｌｅＮｅｅｄｅｄＦｌａｇをセットして、スケジュール変更を起こす
ＩＦ  ＣｕｒｒｅｎｔＴｈｒｅａｄ→ｉＣｓＦｕｎｃｔｉｏｎ  ＆＆  ＣｕｒｒｅｎｔＴｈｒｅａｄ→ｉＣｓＣｏｕｎｔ＝＝０
Ｄｏ  現在のスレッドに対するクリティカル・セクション退出処理
ＥＮＤＩＦ
ＥＮＤＩＦ
カーネルをロック解除する。
【００５１】
競合がないケースでは、このアルゴリズムは、単に２つの変数割当てにまで減ずる。繰り返しになるが、非ＳＭＰシステム上では、このアルゴリズムは、ｉＷａｉｔｉｎｇフラグを調べる間、カーネルをロックするのではなく、割込みを不可能にすることによって、さらに最適化することができ、かつそのように最適化されている。ｉＷａｉｔｉｎｇフラグは、現在のスレッドがミューテックスを保持している間に、別のスレッドがそのミューテックスの獲得を試みた場合、セットされることになる。このフラグは、スレッドのタイムスライスが満了した（優先度が等しい他のスレッドを有するラウンドロビンが、高速ミューテックスが解放されるまで延期される）場合、あるいはスレッドを中断し、または強制終了する試みが行われた場合にも、セットされることになる。後者のシナリオは、スレッドがスレッド・クリティカル・セクションにおいて実行していた（すなわち、ｉＣｓＣｏｕｎｔが非ゼロの）ケースと同様にして扱われる。延期された操作は、高速ミューテックスが解放されると処理され、したがってミューテックス解放コード中のｉＣｓＣｏｕｎｔおよびｉＣｓＦｕｎｃｔｉｏｎの検査が処理される。
【００５２】
ナノカーネルは、スケジューラを含み、このスケジューラは、カーネルがロックされていないことを条件として、割込みサービス・ルーチン（ＩＳＲ）によってキューに入れられた、ペンディング中のアクション、またはペンディング中のスケジュール変更がある場合、ＩＳＲの最後にコールされる。スケジューラはまた、カーネルがロック解除され、ペンディング中のアクションおよびスケジュール変更に関する同じ条件が該当するときは常に呼び出される。
【００５３】
スケジューラは最初に、ＩＳＲによってキューに入れられた、ペンディング中のアクションがあるかどうかを調べ、次いで、実行される準備が整った優先度が最も高いスレッドを選択する。同じ優先度のスレッドは、上述したように、ラウンドロビンに基づいてスケジュールされる。ナノカーネル・スケジューラは具体的には、選択されたスレッドが高速ミューテックスを保持するケースに、以下のように対処する。
・保持されるミューテックスがシステム・ロックの場合、スケジューラは、それ以上の検査をもたないスレッドに直に切り換えるだけでよい。というのは、アドレス空間は、スレッドが最後に稼動してから、変更されていてはならないからである。また、選択されたスレッドを、高速ミューテックスにおいて阻止することはできない（このスレッドは、ある高速ミューテックスを保持し、高速ミューテックス同士はネストしないからである）。
・選択されたスレッドが、システム・ロック以外の高速ミューテックスを保持する場合、スケジューラは、依然としてそのミューテックスに切り換えることができ、フックアウト（ｈｏｏｋ  ｏｕｔ）して、アドレス空間変更を実施する必要はない。というのは、ユーザモード・アドレス空間は、システム・ロック以外の高速ミューテックスによって保護されるクリティカル・セクション中に有効であることを保証されないからである。しかし、ミューテックスのｉＷａｉｔｉｎｇフラグが、高速ミューテックスが解放されたときにアドレス空間変更が実際に起こるようにセットされている場合、アドレス空間変更は、通常は要求されるはずである。さらに、スレッドがＫＴｈｒｅａｄＡｔｔＩｍｐｌｉｃｉｔＳｙｓｔｅｍＬｏｃｋ属性を有し、システム・ロックが現在保持されている場合、ミューテックスのｉＷａｉｔｉｎｇフラグはやはりセットされる。こうすることにより、システム・ロックが保持される間、ミューテックスによって保護されるクリティカル・セクションをスレッドが退出しないことが保証される。
【００５４】
ナノカーネル・スケジューラは、選択されたスレッドが実際に、高速ミューテックスにおいて阻止されるケースに、以下のように対処する。
・高速ミューテックスにおいて阻止される全スレッドは、実行可能リストに残っているので、スケジュール変更中に選択することができる。スレッドに切り換え、そのスレッドを稼動させ、直ちに保持スレッドに切り換えることによって時間を浪費するのではなく、このケースは、スケジューラにおいて調べられ、スケジューラは次いで、スレッドを保持しているミューテックスに直ちに進み、こうすることによって、コンテキスト切換えを省く。この検査は、ＮＦａｓｔＭｕｔｅｘ待ち操作において使われるＹｉｅｌｄＴｏ関数が、ミューテックスが解放されるまで戻ることができないことを保証するものでもある。ｉＷａｉｔＦａｓｔＭｕｔｅｘおよびｉＷａｉｔＦａｓｔＭｕｔｅｘ→ｉＨｏｌｄｉｎｇＴｈｒｅａｄ両方を調べることが必要であることに注目すべきである。というのは、保持スレッドがミューテックスを解放すると、ｉＨｏｌｄｉｎｇＴｈｒｅａｄはＮＵＬＬにセットされるが、ｉＷａｉｔＦａｓｔＭｕｔｅｘは、依然としてそのミューテックスを指すからである。スレッドを保持しているミューテックスへの切換えが実施される場合、上の段落で述べた理由により、いかなるアドレス空間変更も行う必要はない。高速ミューテックスのｉＷａｉｔｉｎｇフラグをここでセットする必要もない。というのは、選択されたスレッドがミューテックスにおいて阻止したときに既にセットされているはずだからである。
【００５５】
本発明は、公知のオペレーティング・システムのカーネルに勝る、以下の重大な利点をもたらすと考えられる。
・相互排他および優先度の継承を単一の機構中に結合させることによって、優先度の継承が、いかなる理由によっても絶たれる可能性が排除される。
・もはや、性能上の理由により、優先度の継承を絶つ動機づけはない。というのは、高速ミューテックスは（その名前が含意するように）、優先度の継承および相互排他機能を単一の機構中に結合させることによる、性能上の不利益を課さないからである。
・この高速で信頼性のある、２つの目的にかなう機構をマイクロカーネル・レベルで提供することは、その上に構築されるどのＯＳも、自動的にデッドロック回避の利益を得ることを意味する。
・高速ミューテックスは、単一のプロセッサおよびＳＭＰシステム両方に適している。
【００５６】
本発明を、特定の実施形態を参照して説明したが、添付の特許請求の範囲によって定義される本発明の範囲内で、変更形態を遂行できることが理解されよう。
【図面の簡単な説明】
【００５７】
【図１】上述した２つのアーキテクチャ・パラダイムの間の主要な違いを示す図である。
【図１】
2007537504.tif 000003
【手続補正書】
【提出日】平成18年2月2日(2006.2.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むスケジューラであって、当該装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドの実行可能リストが保持される、スケジューラを備え、
ロック機構を保持するスレッドを除く全てのスレッドからの、当該装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構をさらに備え、
前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記実行可能リストにおけるその場所から削除されるのではなく、前記ロック機構を保持する前記スレッドが稼動される
ことを特徴とするコンピュータ装置。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１７
【補正方法】変更
【補正の内容】
【請求項１７】
コンピュータ装置を制御する方法であって、
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドの実行可能リストを有する、スケジューラを提供する工程と、
ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構を提供する工程と、
前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記実行可能リストにおけるその場所から削除されるのではなく、前記ロック機構を保持する前記スレッドが稼動されるように調整する工程と、
を備えることを特徴とする方法。
【手続補正３】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１８
【補正方法】変更
【補正の内容】
【請求項１８】
コンピュータ装置用のオペレーティング・システムであって、
異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドの実行可能リストを提供する手段を有する、スケジューラと、
ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構と、
前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記実行可能リストにおけるその場所から削除されるのではなく、前記ロック機構を保持する前記スレッドが稼動されるように調整する手段と、
を備えることを特徴とするオペレーティング・システム。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
本発明の第２の態様によると、コンピュータ装置を制御する方法であって、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドの実行可能リストを有する、スケジューラを提供する工程と、ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構を提供する工程と、前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記実行可能リストにおけるその場所から削除されるのではなく、前記ロック機構を保持する前記スレッドが稼動されるように調整する工程と、を備えることを特徴とする方法が提供される。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２５
【補正方法】変更
【補正の内容】
【００２５】
本発明の第３の態様によると、コンピュータ装置用のオペレーティング・システムであって、異なる優先度を有する実行スレッドの稼動を順序づけるアルゴリズムを組み込むとともに、前記装置上で稼動するようにスケジュールされ、優先度で順序づけられたスレッドの実行可能リストを提供する手段を有する、スケジューラと、ロック機構を保持するスレッドを除く全てのスレッドからの、前記装置の資源へのアクセスを阻止する少なくとも１つの前記ロック機構と、前記スレッドが要求する前記資源がロックされているために、稼動を阻止されるスケジュールされたスレッドは、前記実行可能リストにおけるその場所から削除されるのではなく、前記ロック機構を保持する前記スレッドが稼動されるように調整する手段と、を備えることを特徴とするオペレーティング・システムが提供される。
【国際調査報告】
2007537504.tif 000004
2007537504.tif 000005