JP5676845B2 - コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 - Google Patents

Description

本発明は、コンピュータシステムに関する。より詳しくは、本発明は、複数のオペレーティングシステムを実行するコンピュータシステム上のプロセスにリソースを割り当てることに関する。

コンピュータによって使用されるリソースは、コンピューティング環境によって変化し、また、それらに分散されているが、リソースは、ジョブを実行できるようにする前に、必要とされる。複数のプロセスを同時に実行するとき、それが普通であるが、ボトルネックは、リソースにおいて生じる。これらのボトルネックは、Ｉ／Ｏバスコントローラ、スワップシーケンス中のメモリコントローラにおいて生じることがあり、あるいは、メモリダンプが開始されたときに、それがメモリ負荷を要求するために、プログラムが中断される（preempted）ときにも発生する。

ボトルネックの発生、したがってプロセス飢餓（process starvation）は、複数のオペレーティングシステムを実行するコンピュータシステムでさえも増えている。これらのオペレーティングシステム上で実行されているプロセスが増加すると、複数のプロセスが同じリソースを同時に要求する、又はリソースの解放を互いに待っているプロセスが飢餓する確率が高くなる。

本発明の第１の側面におけるコンピュータシステムは、複数のプロセッサを含む複数のリソースと、複数のカーネルオペレーティングシステムを記憶したメモリとを備える。各オペレーティングシステムは、コンピュータシステム上で実行されるプロセスに対するリソースの割当をそれぞれのリソースの間で調整するカーネルスケジューラを含んでいる。上記複数のプロセッサは、複数のカーネルオペレーティングシステムのうちの異なる１つをそれぞれ実行し、上記複数のカーネルオペレーティングシステムのそれぞれは、他の複数プロセッサの負荷、リソースの有効性及びリソースが有効になるまでの推定時間を含む他の複数のカーネルオペレーティングシステムのリソース情報を交換する。複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の２つ以上を含むものとすることができる。

好ましくは、複数のカーネルスケジューラは、リソース関連情報を、通信プロトコルを用いて共有する。一実施の形態において、通信プロトコルは、共有メモリにアクセスすることを含む。あるいは、通信プロトコルは、プロセス間通信、プロトコルスタック又は伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol：ＴＣＰ／ＩＰ）を含んでいる。あるいは、通信プロトコルは、セマフォ、パイプ（pipes）、信号（signals）、メッセージキュー、データに対するポインタ及びファイル記述子（file descriptors）にアクセスすることを含む。一実施の形態において、プロセスは、互いに通信する少なくとも３つのプロセスからなる。

一実施の形態において、複数のカーネルスケジューラのそれぞれは、他の関係マネージャによってリソースを要求する関係マネージャ（relationship manager）を備える。複数の関係マネージャのそれぞれは、複数のリソースのうちの１つ以上に関するリソース情報を判定するリソースマネージャ（Resource Manager）を備える。リソース情報は、リソースが利用可能になるまでの見積時間（estimated time）である。

本発明の一実施の形態に基づくカーネル動作スケジューラ（ＫＯＳ）の概念図である。 本発明の他の実施の形態に基づくカーネル動作スケジューラ（ＫＯＳ）の概念図である。 本発明の一実施の形態に基づくカーネルプロセススケジューリングの状態遷移図である。 本発明の一実施の形態に基づくＫＯＳ設計の追加機能を有するシステムを示す図である。 本発明の一実施の形態に基づくシステム内のスターコアカーネル構成を示す図である。 本発明の一実施の形態に基づき、チャンネルを介して通信する複数のカーネルのハイレベルのブロック図である。 本発明の一実施の形態に基づき、カーネルスケジューラ間で通信する共有メモリを示す図である。 本発明の一実施の形態に基づく、リソースプロセスを確保するフィルタを有するカーネルスケジューラを示す図である。 複数のリソースをプロセスに割り当てるスター構成のＫＯＳを示す図である。 本発明の実施の形態がオペレーティングシステムの機能をどのように分散するかを示す本発明の一実施の形態に基づくフローチャートである。 符号化プロトコル（encoded protocol）を知らせる、本発明の一実施の形態に基づくカーネルスケジューラを示す図である。 本発明の実施の形態に基づく通信ポートを介して、プロセスがどのように通信するかを示すブロック図である。 リソースを、本発明の一実施の形態に基づくオペレーティングシステムにマッピングするテーブルを示す図である。 リソース情報を、共有メモリを用いて交換する独立したカーネルスケジューラを示す図である。 図１５Ａは、複数のオペレーティングシステムのそれぞれが有する、他のオペレーティングシステムの状態を示すテーブルを示す図であり、 図１５Ｂは、複数のオペレーティングシステムのそれぞれが有する、他のオペレーティングシステムの状態を示すテーブルを示す図であり、 図１５Ｃは、複数のオペレーティングシステムのそれぞれが有する、他のオペレーティングシステムの状態を示すテーブルを示す図である。 本発明の一実施の形態に基づく独立したカーネルスケジューラによって用いられ、交換されるリソース情報を示す図である。 本発明の一実施の形態に基づく独立したカーネルスケジューラが、どのようにリソース情報を交換するかを示すハイレベルの図である。 本発明の一実施の形態に基づくオペレーティングシステムカーネルを介して、リソースをプロセスにどのように割り当てるかを示すハイレベルの図である。 コマンドカーネルと、その関係マネージャと、３つのリソースとのハイレベルのブロック図である。 プロセス識別子と、プロセス識別子が割り当てられたリソースと、プロセスの優先度とを格納する本発明の一実施の形態に基づくプロセステーブルを示す図である。 本発明の一実施の形態に基づくオペレーティングシステムに、リソースを割り当てる方法を示すフローチャートである。 本発明の一実施の形態に基づくオペレーティングシステムカーネルに、基準を用いて、プロセスを割り当てる方法のフローチャートである。 本発明の一実施の形態に基づくオペレーティングシステムに、プロセスを割り当てるシーケンスを示す図である。

本発明に基づく、直列に動作する（run in tandem）複数のオペレーティングシステムは、リソースを必要とするプロセスに割り当てるリソースを共有し、これによって、ボトルネック及びリソース競合の他の徴候を低減する。一実施の形態において、リソースは、リソースを必要とするプロセスにリソースを割り当てるオペレーティングシステムを調整する中央のカーネル動作スケジューラ（central kernel operating scheduler）を用いて、集中的に割り当てられる。他の実施の形態において、リソースは、ピアツーピア方式で、リソースの配分をそれら自体で調整するオペレーティングシステムによって供給される。この実施の形態では、オペレーティングシステムは、確立されたプロトコル（well-established protocols）を用いて、通信する。

本発明においては、コンピュータシステム上で実行される幾つかのオペレーティングシステムは、特定のタスクを実行するように特化されている。特定のリソース割当に対する要求を実行するように特化されたオペレーティングシステムでは、他の要求が溜まっている（backlogged）リソースに対する要求が受信されると直ちに、オーバフローした要求は、中央のオペレーティングシステム（centralized Operating System）ではなく、リソースオペレーティングシステムによって、単にキューに入れられる。

プロセス管理（Process management）
カーネルの主な仕事は、アプリケーションの実行を許可し、例えばハードウェアを抽象化する機能によって、アプリケーションを支援することである。プロセスは、アプリケーションがどのメモリ部分にアクセスできるかを定義する（この導入部では、プロセス、アプリケーション及びプログラムは、同義語として用いられている）。カーネルのプロセス管理は、メモリ保護が組み込まれたハードウェアを考慮しなければならない。

アプリケーションを動作させるために、カーネルは、通常、アプリケーション用のアドレス空間を準備して、（多くの場合は、デマンドページングによって、）アプリケーションのコードを含むファイルをメモリにロードし、プログラムのスタックを準備して、プログラム内の所定の位置に分岐するように、アプリケーションの実行を開始する。

マルチタスクのカーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。通常、コンピュータシステムが同時に動作させることができるプロセスの数は、実装されているＣＰＵの数に等しい（なお、プロセッサが同時マルチスレッディング（simultaneous multithreading）をサポートしている場合は、この限りではない）。

プリエンプティブマルチタスクシステム（preemptive multitasking system）では、カーネルは、タイムスライスを全てのプログラムに与え、これらのプロセスが同時に実行されているかのようにユーザに見せるほど速く、プロセスから他のプロセスに切り換える。カーネルは、スケジューリングアルゴリズムを用いて、次にどのプロセスを動作させるか、及びどのくらいの時間を与えるかを決定する。選択されたスケジューリングアルゴリズムは、あるプロセスに他のプロセスよりも高い優先度を与えることができる。また、カーネルは、通常、これらのプロセスに、通信する方法を提供する。この方法は、プロセス間通信（inter-process communication：ＩＰＣ）と呼ばれ、主な手法は、共有メモリ（shared memory）、メッセージパッシング（message passing）及びリモートプロシージャコール（remote procedure calls）である。

他のコンピュータシステム（特に、より小型で、より性能が低いコンピュータ）は、協調的マルチタスク（co-operative multitasking）を有し、協調的マルチタスクでは、各プロセスは、他のプロセスに切り換えてもよいことをカーネルに告げる特別な要求を出すまでは、中断することなく、動作することができる。このような要求は、「明け渡し（yielding）」と呼ばれ、通常、プロセス間通信の要求に応じて、あるいは発生するイベントを待つために、起こる。Windows（登録商標）及びＭａｃＯＳ（登録商標）の旧バージョンは、何れも、協調的マルチタスクを用いていたが、これらは、対象のコンピュータの性能が高まったので、プリエンプティブ方式に切り換えられた。

また、オペレーティングシステムは、マルチプロセス（対称型マルチプロセッサ（Symmetric Multiprocessor：ＳＭＰ）又は非均質メモリアクセス（Non-Uniform Memory Access））をサポートしていることもある。この場合、異なるプログラム及びスレッドは、異なるプロセッサ上で動作することができる。このようなオペレーティングシステムのカーネルは、カーネルがそのコードの２つの異なる部分を同時に問題なく動作できることを意味するリエントラント（re-entrant）となるように設計しなければならない。これは、通常、２つのプロセッサが同時に同じデータを変更しようとしないことを保証する同期機構（例えばスピンロック（spinlock））を設けることを意味する。

メモリ管理（Memory Management）
オペレーティングシステムには、通常、カーネル、すなわちコンピュータの中核として動作する一群の中心的な制御プログラム（centralized control program）が組み込まれている。これらの制御プログラムの中には、次のプロセスに対してＣＰＵ時間を直列に予約する役割を果たすスケジューラプログラムが含まれている。本発明は、１ＣＰＵ当たり１オペレーティングシステムであって、複数のＣＰＵ上で動作する複数のオペレーティングシステムを用いる。各オペレーティングシステムは、カーネル動作スケジューラ（Kernel Operational Scheduler：ＫＯＳ）と呼ぶ独特なスケジューラプログラムを有する専用のカーネルを有する。全てのＫＯＳは、初期化中に、それ自体を構成する能力を有し、コンピュータシステムに搭載されている各ＣＰＵ用のオペレーティングシステムカーネル（operating system kernel）のバイナリコードのコピーをシステム生成（sysgen）する（システム生成とは、特定の、独自に定められたオペレーティングシステム、又は独立したソフトウェアコンポーネントを組み合わせることによって、他のプログラムを生成することを意味する）。各カーネルが、一旦、適切に準備されて、各ＣＰＵに連結されると、ＫＯＳスケジューラ（KOS schedulers）は、各カーネル間の通信を確立し、どのカーネルがどのリソースを制御するかを決定する。

カーネルの様々な設計法（Kernel-Wide Design Approaches）
上述したタスク及び特徴は、当然、設計及び実装が互いに異なる様々な方法で提供することができる。

マイクロカーネル（microkernel）の原理とモノリシックカーネル（monolithic kernel）の原理の根本的な違いは、メカニズム（mechanism）とポリシ（policy）の分離の原理である。ここで、メカニズムとは、多くの異なるポリシを実装できる支持体（support）であり、一方、ポリシとは、特定の動作モード（mode of operation）である。必要最低限のマイクロカーネルの中には、幾つかの非常に基本的なポリシのみが含まれており、そのメカニズムによって、（メモリ管理、ハイレベルのプロセススケジューリング、ファイルシステム管理等のような）ポリシのうちのどのポリシを採用すべきかを決定する基本的なポリシが、カーネルの一番上（オペレーティングシステムの残りの部分及び他のアプリケーションよりも上部）で動作することができる。一方、モノリシックカーネルは、それよりも多くのポリシを含む傾向にあり、したがって、オペレーティングシステムの残り部分は、これらのポリシに依存するように制限される。このメカニズムとポリシの分離を適切に行わないことは、既存のオペレーティングシステムにおける重大な技術革新の欠如の主な原因であり、コンピュータアーキテクチャにおける共通の問題である。モノリシックカーネル設計は、保護に対するカーネルモード／ユーザモード構成法（kernel mode/user mode architectural approach、技術的には、多段階保護領域（hierarchical protection domain）構成法と呼ばれる）によって行われ、これは、従来の商用オペレーティングシステムにおいて一般的である。したがって、保護を必要とするあらゆるモジュールは、実際に、カーネルに入れられている。モノリシックカーネル設計と特権モード（privileged mode）間のこのリンクは、メカニズムとポリシの分離の重要な問題に帰結し、実際、特権モード構成法（privileged mode architectural approach）は、保護メカニズム（protection mechanism）をセキュリティポリシ（security policy）に融合し、一方、主要な他の構成法（architectural approach）、能力ベースのアドレッシング（capability-based addressing）は、この２つを明確に区別し、自然に、マイクロカーネル設計に通じる（保護とセキュリティの分離を参照）。

モノリシックカーネルは、それらのコードの全てを、同一のアドレス空間（カーネル空間）で実行するが、マイクロカーネルは、それらのサービスの殆どを、ユーザ空間で動作させることによって、コードベース（codebase）の保守性及びモジュール性を向上させることを意図している。殆どのカーネルは、厳密には、これらの分類の１つに収まらず、これらの２つの設計の中間に位置する。これらは、ハイブリッドカーネル（hybrid kernel）と呼ばれる。より斬新な設計、例えばナノカーネル（nanokernel）及びエクソカーネル（exokernel）が利用可能であるが、製品のオペレーティングシステムとしては殆ど使用されていない。例えば、Ｘｅｎハイパーバイザー（Xen hypervisor）は、エクソカーネルである。

モノリシックカーネル（Monolithic Kernel）
モノリシックカーネルのダイヤグラム
モノリシックカーネルでは、全てのＯＳサービスは、主要なカーネルスレッド（kernel thread）と一緒に動作し、したがって、同じメモリ領域に存在する。この方法は、豊かで強力なハードウェアアクセスを提供する。何人かの開発者、例えばＵＮＩＸ（登録商標）開発者であるケン・トンプソン（Ken Thompson）は、他の解決法に比べて、モノリシックカーネルのオペレーティングシステムは、設計及び実装が容易であると主張している。モノリシックカーネルの主な短所は、オペレーティングシステムのコンポーネント間の依存性、例えばデバイスドライバにおけるバグがオペレーティングシステム全体をクラッシュさせる可能性があり、大きなカーネルは、保守が非常に難しいという事実がある。

マイクロカーネル（Microkernel）
マイクロカーネル法（microkernel approach）では、カーネル自体は、以前のカーネルの機能、例えばデバイスドライバ、ＧＵＩサーバ等を承継した独立のプログラムをサーバが実行できるようにする基本機能だけを備える。

マイクロカーネル法は、必要最低限のＯＳサービス、例えばメモリ管理、マルチタスク及びプロセス間通信を実行する一連の基本命令（primitive）、すなわちシステムコール（system call）によって、ハードウェアの単純な抽象化（abstraction）を定義することを含んでいる。通常、カーネルが提供するサービスを含む他のサービス、例えばネットワークサービスは、サーバと呼ばれるユーザ空間のプログラムで実行される。マイクロカーネルは、モノリシックカーネルに比べて簡単に保守することができるが、システムコール及びコンテキストスイッチ（context switch）が多くなり、このようなシステムコール及びコンテキストスイッチは、典型的に、単純な関数コール（plain function call）に比べて、より大きなオーバヘッドを発生するので、処理速度が低下する可能性がある。

マイクロカーネルでは、オペレーティングシステムの残りの部分を、高級言語で書かれた普通のアプリケーションプログラムとして実装することができ、同じカーネルを、変更することなく、異なるオペレーティングシステム上で用いることができる。また、複数のオペレーティングシステム間を動的に切り換えて、複数のオペレーティングシステムを同時にアクティブにすることができる。

モノリシックカーネル対マイクロカーネル
コンピュータのカーネルが進化するにつれ、幾つかの問題が明らかになってきた。最も明白な問題の１つは、メモリ使用量（footprint）が増えるということである。これは、仮想メモリシステムを改良することによって、ある程度軽減されるが、全てのコンピュータアーキテクチャが仮想メモリをサポートしているわけではない。カーネルのメモリ使用量を少なくするためには、大規模な編集を行い、不必要なコードを注意深く除去する必要があり、これは、数百万ものコード行を有するカーネルの部分間の相互依存性が理解し難いので、非常に困難である。モノリシックカーネルが抱える問題のために、モノリシックカーネルは、１９９０年代初頭には、時代遅れであるとみなされていた。この結果、マイクロカーネルではなく、モノリシックカーネルを採用したＬｉｎｕｘ（商標）の設計は、リーヌス・トーヴァルズ（Linus Torvalds）と、アンドリュー・タネンバウム（Andrew Tanenbaum）との間の有名な議論の主題となった。タネンバウム／トーヴァルズ議論では、何れの意見にも長所があった。初期のＵＮＩＸの開発者ケン・トンプソン（Ken Thompson）を含む何名かは、マイクロカーネル設計は、美的に魅力があるが、モノリシックカーネルの方がより簡単に実装できると主張した。しかしながら、モノリシックカーネルのオペレーティングシステムにおけるバグは、通常、オペレーティングシステム全体をクラッシュさせ、一方、サーバがメインスレッドとは別に動作するマイクロカーネルでは、このようなことは起こらない。モノリシックカーネルの支持者は、間違ったコードがカーネルに入ることはなく、また、マイクロカーネルは、コードが正しいことによる利点を殆ど提供しないと結論づけている。マイクロカーネルは、多くの場合、クラッシュに対する耐性（crash tolerance）が重要な埋め込み型のロボット用コンピュータ又は医療用コンピュータにおいて用いられており、殆どのＯＳのコンポーネントは、それ自体に専用の保護されたメモリ空間に存在する。これは、モノリシックカーネルでは不可能であり、最新のモジュールローディングのモノリシックカーネルでも不可能である。

性能（Performance）
モノリシックカーネルは、システム性能を高めるために、そのコードの全てを同じアドレス空間（カーネル空間）に有するように設計されている。何人かの開発者、例えばＵＮＩＸの開発者のケン・トンプソンは、モノリシックカーネルのオペレーティングシステムは、プログラムを上手く書けば、非常に効率が良いと主張している。マイクロカーネル設計における、通常メッセージパッシング（message passing）に基づくプロセス間通信（ＩＰＣ）方式は低速であり、モノリシックモデルは、このＩＰＣではなく、共有カーネルメモリを用いることによって、より効率が良い傾向にある。

１９８０年代及び１９９０年代初頭に構成されたマイクロカーネルの性能は、劣っていた。特定のマイクロカーネルの幾つかの性能を実験に基づいて測定した研究でも、このような効率が悪い理由は解析されなかった。これらの性能に関する説明は、カーネルモードからユーザモードに切り換える周波数を高め（なお、保護のこのような多段階設計は、マイクロカーネルに固有なものではない）、プロセス間通信の周波数を高め（なお、ＩＰＣは、以前に信じられていた速度よりも一桁速く実行することができる）、及びコンテキストスイッチの周波数を高めることによる一般的で、証明されていない考えを有する伝説（folklore）とされた。実際、これらの性能が低い理由は、１９９５年に推測されたのと同様に、（１）全てのマイクロカーネル法の実際の効率の悪さ、（２）これらのマイクロカーネルに実装された特定の概念、（３）これらの概念の特定の実装のためである。したがって、効率の良いマイクロカーネルを構成する解決法がある場合、以前の試みと異なり、正しい構成技術を適用する研究が残された。

一方、モノリシックカーネルの設計に通じる多段階保護領域のアーキテクチャは、保護の異なるレベル間で相互作用がある毎に（すなわち、プロセスが、データ構造をユーザモードとスーパバイザモード（supervisor mode）の両方で処理しなければならいときに）、重要性によってメッセージをコピーする必要があるので、重大な性能の低下を有している。殆どの研究者は、ｌ９９０年代半ばまでに、注意深く調整することによって、このオーバヘッドを劇的に削減できるという考えを諦めたが、近年、より新しいマイクロカーネルは、性能を上げるために、最適化されている。

ハイブリッドカーネル（Hybrid kernel）
ハイブリッドカーネル法（hybrid kernel approach）は、モノリシックカーネルの速さ及び設計の容易さを、マイクロカーネルのモジュール性及び実行時の安全性と組み合わせることを試みたものでである。

ハイブリッドカーネルは、本質的には、モノリシックカーネル法（monolithic kernel approach）とマイクロカーネルのオペレーティングシステム間の妥協案である。これは、従来のマイクロカーネルの性能におけるオーバヘッドを低減するために、幾つかのサービス（例えばネットワークスタック又はファイルシステム）はカーネル空間で動作させるが、カーネルコード（例えばデバイスドライバ）はユーザ空間のサーバとして動作させることを意味する。

ナノカーネル（Nanokernel）
ナノカーネルは、割込コントローラ、すなわちタイマのような最も基本的なサービスさえも含む全てのサービスを、実質的に、デバイスドライバに委ね（delegate）、カーネルに必要なメモリを、従来のマイクロカーネルよりも更に少なくしている。

エクソカーネル（Exokernel）
エクソカーネルは、ハードウェアを理論モデルに抽象化しない種類のカーネルである。論理モデルの代わりに、エクソカーネルは、物理的ハードウェアリソース、例えばＣＰＵ時間、メモリページ及びディスクブロックを異なるプログラムに割り当てる。エクソカーネル上で動作するプログラムは、エクソカーネルを用いて周知のＯＳの抽象化をシミュレートするライブラリオペレーティングシステムにリンクすることができ、あるいは、性能を高めるために、特定用途向けの抽象化を行うことができる。

スケジューリング（Scheduling）
スケジューリングは、コンピュータのマルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプト（key concept）である。スケジューリングは、優先順位付きキュー（priority queue）の優先度を、プロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。

また、スケジューラは、リアルタイム環境、産業界における自動制御のためのモバイル機器（例えばロボティクス）では、プロセスがデッドラインに間に合うことを保証するようにしなければならない。これは、オペレーティングシステムを安定に保つためには重要である。スケジューリングされたタスクは、モバイル機器に送られて、管理用のバックエンド（administrative back end）によって管理される。

オペレーティングシステムのスケジューラの種類
オペレーティングシステムは、長期スケジューラ（別名、入力スケジューラ（admission scheduler））、中間的又は中期スケジューラ、及び短期スケジューラ（別名、ディスパッチャ（dispatcher））といった最大３つの異なる種類のスケジューラを備えることができる。

長期スケジューラ、すなわち入力スケジューラは、どのジョブ又はプロセスを実行可能キューに入れるかを決定し、すなわち、長期スケジューラは、プログラムを実行しようとするとき、それを現在実行しているプロセスの組に直ちに追加するか、遅延して追加するかを決定する。したがって、この長期スケジューラは、オペレーティングシステム上でどのプロセスを動作させるかを決定する（dictate）とともに、同時にサポートする並列性の程度を決定し、すなわち、同時に実行するプロセスの数を多くするか少なくするか、処理するＩ／Ｏ負荷が高いプロセス（I/O intensive process）とＣＰＵ負荷が高いプロセス（CPU intensive process）とをどのように分けるかを決定する。通常、デスクトップコンピュータでは、このような長期スケジューラは存在せず、プロセスは、自動的にオペレーティングシステムに許可される。しかしながら、プロセスのデッドラインを間に合わせるオペレーティングシステムの能力は、オペレーティングシステムが問題なく処理できるプロセスの数よりも多くを許可することによって生じる処理速度の低下（slowdown）及び競合（contention）によって、低下するので、リアルタイムオペレーティングシステムでは、この種のスケジューリングが非常に重要である。

中期スケジューラは、仮想メモリを有する全てのオペレーティングシステムに存在し、プロセスを、メインメモリ（main memory）から２次メモリ（secondary memory、例えばディスクドライブ）に一時的に退避させ、また、これとは逆に、２次メモリからメインメモリに戻す。このような処理は、一般的に、スワップアウト（swapping out）とスワップイン（swapping in）と呼ばれる（不正確ではあるが、ページアウト（paging out）とページイン（paging in）とも呼ばれる）。中期スケジューラは、ある時間アクティブでないプロセス、優先度が低いプロセス、頻繁にページフォールトを起こしているプロセス、又は大量のメモリを確保しているプロセスを、スワップアウトして、メインメモリを他のプロセスに空け、後で、より多くのメモリが利用可能となったとき、あるいはプロセスのブロックが外されて、リソースを最早待たなくなったときに、これらのプロセスをスワップインして、メインメモリに戻すことを決定する。

今日の多くのオペレーティングシステム（スワップファイル以外に、仮想アドレス空間を補助記憶装置にマッピングすることをサポートしたオペレーティングシステム）では、中期スケジューラは、バイナリコードを実行するときに、バイナリコードをスワップアウトされたプロセスとして取り扱うことによって、実際には、長期スケジューラの役割を果たしている。このように、バイナリコードの一部が必要なときに、バイナリコードの一部は、要求があり次第、スワップインすることができ、又はゆっくりとロード（lazy loaded）することができる。

短期スケジューラ（別名、ディスパッチャ）は、クロック割込、Ｉ／Ｏ割込、オペレーティングシステムコール又は他の形式の信号の後、実行可能な状態でメモリ内にあるプロセスのうちのどのプロセスを次に実行する（ＣＰＵを割り当てる）かを決定する。したがって、短期スケジューラは、長期スケジューラ又は中期スケジューラに比べてより頻繁に、スケジューリングの決定を行う。スケジューリングの決定は、タイムスライス毎に、最小限、すなわち非常に短い時間で行う必要がある。この短期スケジューラは、スケジューラがＣＰＵに他のプロセスを割り当てると決定したときに、ＣＰＵからプロセスを強制的に排除することができることを意味するプリエンプティブ（preemptive）であってもよく、あるいは、スケジューラがＣＰＵからプロセスを除去することを強制できないノンプリエンプティブ（non-preemptive）であってもよい。

スケジューリング規則（scheduling disciplines）
スケジューリング規則は、同時且つ非同期でリソースを必要とするパーティ間に、リソースを割り当てるために用いられるアルゴリズムである。スケジューリング規則は、（スレッド及びプロセス間でＣＰＵ時間を共有する）オペレーティングシステムだけでなく、（パケットトラヒックを処理する）ルータにおいても用いられる。

スケジューリングアルゴリズムの主要な目的は、リソース飢餓（resource starvation）を最小にするとともに、リソースを利用するパーティ間で公平性を保証することである。

オペレーティングシステムにおけるスケジューラの実装
異なるコンピュータオペレーティングシステムは、異なるスケジューリング方式を実装している。ＭＳ−ＤＯＳ及びマイクロソフトの非常に初期のWindowsシステムは、マルチタスクではなく、それ自体は、スケジューラを必要としなかった。Windows3.1ベースのオペレーティングシステムは、単純なノンプリエンプティブスケジューラ（non-preemptive scheduler）を使用しており、プログラマは、ＣＰＵ時間を他のプロセスに与えるために、ＣＰＵ時間を明け渡す（yield、ＣＰＵを解放する）ように、プロセスに命令することが必要であった。このノンプリエンプティブスケジューラは、マルチタスクを原始的にサポートしているが、より高度なスケジューリングの選択肢を備えていなかった。

WindowsNT4.0ベースのオペレーティングシステムは、多段フィードバックキュー（multilevel feedback queue）を使用している。WindowsNT4.0ベースのオペレーティングシステムにおける優先度は、１〜３１であり、１〜１５の優先度は、ノーマル優先度であり、１６〜３１の優先度は、特権を割り当てる必要があるソフトリアルタイム優先度である。ユーザは、タスクマネージャアプリケーションから又はスレッド管理ＡＰＩによって、これらの優先度から５段階の優先度を選択して、実行アプリケーションに割り当てることができる。

初期のＵＮＩＸシステムの実装では、多段フィードバックキューのスケジューラが使用されており、各フィードバックキュー内では、ラウンドロビン方式で選択を行っている（round robin selection）。このＵＮＩＸシステムでは、プロセスが生成されると、プロセスは、最優先キューに置かれ（新しいプロセス、例えば１回のマウスの移動又はキーストロークに関係したプロセスに対する応答時間を短くして）、ＵＮＩＸシステム内でＣＰＵ時間を消費していくと、複数回に亘ってプリエンプト（preempt）され、最終的には、最低優先度のキューに入れられる。しかしながら、このＵＮＩＸシステムでは、新しいプロセスが絶え間なく生成されると、古いプロセスは、ＣＰＵ時間の飢餓になる可能性があり、したがって、ＵＮＩＸシステムが、新しいプロセスを生成速度よりも速く処理できない場合、飢餓を回避することはできない。ＵＮＩＸシステムでは、プロセス優先度を４０段階のうちの１つに明示的に設定できたが、最新のＵＮＩＸシステムでは、これ以上の数の優先度を利用することができる（Solarisは、１６０段階の優先度を有する）。優先度が低いプロセスの飢餓に対するWindowsNT4.0の解決法（プロセスが飢餓すると、このプロセスをラウンドロビンキューの先頭に上げる）とは異なり、初期のＵＮＩＸシステムは、巧妙な時間経過方式を用いており、すなわち、飢餓しているプロセスの優先度を、実行されるまで徐々に高め、プロセスが実行されると、優先度を、飢餓が始まる前の値にリセットする。

Ｌｉｎｕｘカーネルは、バージョン２．６．２２までは、Ｏ（１）スケジューラ（O(1) scheduler）を用いていたが、このバージョン２．６．２３からは、完全公平スケジューラ（Completely Fair Scheduler）に切り換えられている。

スケジューリングアルゴリズム
コンピュータ科学において、スケジューリングアルゴリズムは、システムリソース、通常はＣＰＵ時間に対するアクセスを、スレッド又はプロセスに与える方法である。スケジューリングアルゴリズムは、通常、システムに負荷を効率的に分散するために行われる。スケジューリングアルゴリズムの必要性は、マルチタスクを実行する、すなわち複数のプロセスを同時に実行する最新のオペレーティングシステムの殆どの要求から生じている。スケジューリングアルゴリズムは、通常、タイムスライス多重化カーネル（time slice multiplexing kernel）においてのみ用いられる。この理由は、システムに負荷を効率的に分散させるためには、タイムスライス多重化カーネルは、次のスレッドの実行を開始するために、現スレッドの実行を強制的に中断（suspend）できなければならない。

使用されるスケジューリングアルゴリズムは、循環リスト（cycling list）内の各プロセスに、所定の等しい時間（例えば１ｍｓ、通常は、１ｍｓ〜１００ｍｓ）を与えるラウンドロビン方式のように簡単にすることができる。したがって、プロセスＡが１ｍｓ間実行され、次にプロセスＢが１ｍｓ間実行され、次にプロセスＣが１ｍｓ間実行され、次にプロセスＡに戻る。

より高度なスケジューリングアルゴリズムでは、プロセスの優先度、すなわちプロセスの重要度を考慮する。これにより、あるプロセスは、他のプロセスよりも長いＣＰＵ時間を使うことができる。なお、カーネルは、常に、オペレーティングシステムの適切な機能を保証するために必要とされる何らかのリソースを使用しており、したがって、無限の優先度を有すると言うことができる。対称型マルチプロセッサ（Symmetric Multiprocessor：ＳＭＰ）システムでは、プロセッサアフィニティ（processor affinity）が、プロセス自体の動作速度を遅くする原因であっても、全体的なシステム性能を高めると考えられている。プロセッサアフィニティは、一般的に、キャッシュスラッシング（cache thrashing）を減少させることによって、性能を向上させる。

Ｉ／Ｏスケジューリング
この章は、Ｉ／Ｏスケジューリングに関する説明であり、Ｉ／Ｏスケジューリングは、プロセススケジューリングとは異なるものである。Ｉ／Ｏスケジューリングは、ブロックされたＩ／Ｏ動作をディスクサブシステムに送る順番を決定するために、コンピュータオペレーティングシステムで用いられる方法を記述する用語である。Ｉ／Ｏスケジューリングは、ディスクスケジューリング（disk scheduling）とも呼ばれる。

目的
Ｉ／Ｏスケジューラ（I/O scheduler）は、Ｉ／Ｏスケジューラの目標に応じて、多くの目的を有することができ、以下、共通の目標を示す。

・ハードディスクのシークによって浪費される時間を最小にする。
・特定のプロセスのＩ／Ｏ要求を優先させる。
・ディスク帯域幅を動作中の各プロセスに割り当てる。
・特定のデッドラインの前に、ある要求が発行されることを保証する。

実装
Ｉ／Ｏスケジューリングは、通常、ハードディスクによって機能しなければならず、ディスクヘッドを現在の位置から遠く離れた位置に移動する（この動作は、シークと呼ばれる）要求のために、アクセス時間が長くなるという特性を有する。このシーク動作がシステム性能に与える影響をできるだけ少なくするために、殆どのＩ／Ｏスケジューラは、ランダムな順番で入力された要求を、ディスク上で検出される順番に並べ替える種々のエレベータアルゴリズム（elevator algorithm）を実装している。

一般的なディスクスケジューリング規則
・ランダムスケジューリング（Random Scheduling：ＲＳＳ）
・先入先出（First In, First Out：ＦＩＦＯ）、別名、先着順サービス（First Come First Served：ＦＣＦＳ）
・後入先出（Last In, First Out：ＬＩＦＯ）
・最短シーク順（Shortest seek first）、別名、最短シーク／サービス時間順（Shortest Seek / Service Time First：ＳＳＴＦ）
・エレベータアルゴリズム（Elevator algorithm）、別名、ＳＣＡＮ（その変種Ｃ−ＳＣＡＮ、ＬＯＯＫ及びＣ−ＬＯＯＫを含む）
・一度にＮ個のレコードをスキャンするＮステップＳＣＡＮ（N-Step-SCAN）
・ＦＳＣＡＮ、ＮがＳＣＡＮサイクルの最初のキューサイズに等しいステップＳＣＡＮ（Step-SCAN）
・完全公平キューイング（Completely Fair Queuing：ＣＦＱ（Ｌｉｎｕｘ））
・予測スケジューリング（Anticipatory scheduling）

図１は、本発明の一実施の形態に基づくＫＯＳスケジューラオペレーティングシステム（KOS scheduler operating system）１００を示す概略図である。ＫＯＳスケジューラオペレーティングシステム１００は、単一メモリ内で実行される複数のオペレーティングシステム１０１〜１０６を含み、全てのオペレーティングシステム１０１〜１０６は、外殻１１５で示すアプリケーションとインタフェースしている。

図２は、本発明の他の実施の形態に基づくＫＯＳスケジューラオペレーティングシステム１２０を示す概略図である。ＫＯＳスケジューラオペレーティングシステム１２０は、単一メモリ内で実行される複数のオペレーティングシステム１２１〜１２６を含み、オペレーティングシステム１２１〜１２６は、外殻１３０で示すリソースとインタフェースしており、リソースは、外殻１３５で示すアプリケーションとインタフェースしている。

マルチＯＳのＫＯＳシステム
マルチタスクにおいて、カーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大の数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。本発明は、この錯覚を、プロセッサの数を１つから２つ以上に増やすことによって現実のものとし、イベントを、リソースを要求するイベントとして、通信、スケジューリング、委託（delegated）、ルーティング及び外注（outsource）する特別に設計されたスケジューラソフトウェアを用いて、互いに同時に機能する、コンピュータシステムに実際に搭載されたオペレーティングシステムの数を増やすＫＯＳ設計を実際に提案する。通常、オペレーティングシステムが同時に動作させることができるプロセスの数は、搭載されているＣＰＵの数に等しい（なお、プロセッサが同時マルチスレッディングをサポートしている場合は、この限りではない）。本発明の好ましい実施の形態は、複数のＣＰＵが搭載されていることを必要とし、最大の性能を発揮するためには、協調して同時に機能するオペレーティングシステムの数が、搭載されているＣＰＵの数に等しくなければならないことを、提案する。また、ＵＮＩＸ−ＫＯＳ設計も、各オペレーティングシステムカーネル内でマルチスレッディングが実行され続けることを提案しているが、ＫＯＳスケジューラは、アプリケーションによって必要とされるリソース及び各オペレーティングシステムによってサポートされているリソースに基づいて、アプリケーションプログラムを、インストールされている各オペレーティングシステムに／から通信、外注及びルーティングすることが残されている。

ＫＯＳ概念
分散カーネル動作スケジューラ（分散ＫＯＳ）は、他のカーネル動作スケジューラと同期して動作する分散オペレーティングシステムである。各ＫＯＳは、他の同様なＫＯＳと並列して動作し、ある所定のコンピュータシステム環境内には２つ以上のオペレーティングシステムがあり、ある特定のコンピュータには２つ以上のＣＰＵが存在するが、これらの環境は、シングルコンピュータシステムとみなされる。幾つかの用語法（nomenclature）では、分散コンピューティング（distributed computing）とは、コンピュータリソース（computing resources）が多くの異なるコンピュータプラットフォームに分散され、全てのコンピュータリソースが、１つの主題の下に協調して（in concert）機能するものと定義される。ＫＯＳは、これに類似しているが、分散ＫＯＳは、シングルコンピュータシステム環境内にあり、互いに非常に密接し、シングルコンピュータシステムとして動作する点だけが異なる。各ＫＯＳは、単一カーネル内にある。各カーネルは、単一のスケジューラを有し、この単一スケジューラは、ＫＯＳが、イベントをスケジューリングする種類の他の同様のＫＯＳと通信する通信機能を有するように設計された後は、このＫＯＳによって置換される。

データ処理は、一連のイベントに分割することができ、これによって、各イベントは、データ処理を完了するためには、ある程度のコンピュータリソースを必要とする。スケジューラは、ＣＰＵ時間、リソース及び優先度をイベントに割り当てるタスクを有する、カーネル内で最も責任があるプログラムである。したがって、ＣＰＵ時間のリソースを時分割シナリオ（time-sharing scenario）の下でスケジューリングする場合、特定のイベントには、その特定のイベントを完了するために必要とされるあらゆるリソースと、残りのリソース、例えばメモリ、一時的なＩ／Ｏバスの優先度等とが与えられる。本発明に基づくＫＯＳは、シングルシステム当たり複数のＫＯＳが存在するカーネル動作スケジューラであり、各ＫＯＳは、同時に動作するとともに、完了するためにコンピュータリソースを必要とする同時発生事象（simultaneous events）上での実行を管理する。更に、各ＫＯＳは、カーネル環境空間、あるいはこのようなリソースが制限又は不足しているときのメモリの共有部分内のセマフォによって制御される、同様のリソースを必要とする場合がある。分散ＯＳであるＫＯＳ及びそのコアであるスケジューラは、汎用ＣＰＵハードウェアに結び付けられた分散コンピューティングであり、各分散ＯＳは、初期化時に固有のＩＤを有し、このようなＩＤは、各ＫＯＳに割り当てられる。

ＵＮＩＸシステムのＩＰＣ（Unix System IPC）
ＩＰＣ機能及びプロトコルスタック（IPC Facilities and Protocol Stacks）
ＩＰＣ機能及びプロトコルスタックは、ＵＮＩＸ構造に常駐し、ユーティリティとして既に統合されている。これらのユーティリティは、ＵＮＩＸ構造の下で、オペレーティングシステム間の通信を行うために、用いられる。

表１は、ＩＰＣの種類を、ＫＯＳがサポートする特定のリソースにマッピングした表である。表１の情報を参照すると、最初の行の７つのＩＰＣの種類は、ローカルカーネル（local kernel）及びスケジューラオペレーティングシステム内のプロセス間の通信に用いられ、最後の２つの行は、同じコンピュータ上であるが、同じコンピュータシステム上の複数のＣＰＵに分散されているオペレーティングシステム間の通信のために用いられる。

ＳＴＲＥＡＭＳのＬｉｎｕｘサポートは、「ＬＩＳ」と呼ばれる独立したオプションのパッケージとして入手可能である。

表１の最初の行の７つのＩＰＣの形式は、通常、同じホストオペレーティングシステム上のプロセス間のＩＰＣに制限される。異なるホスト上のプロセス間のＩＰＣのために一般的にサポートされるものは、最後の２つの行のソケット及びＳＴＲＥＡＭＳのみである。

カーネルスケジューラ
カーネルスケジューラは、現処理をどこで行うかを決定するために必要とされるリソースをフィルタリングし、選択する機能を有する。例えば、各ＣＰＵは、通常、汎用のＣＰＵであり、それに対して、各ＫＯＳは、より特化されている。ポインタ及びファイル記述子（file descriptors）が、実際のファイルデータの代わりに、各ＫＯＳ間で受け渡されるように、メモリの一部は、各ＫＯＳ間で共有される。ＩＰＣ機能を用いることによって、任意のプロセスを、複数のＣＰＵに亘って、及び複数のＫＯＳに亘って移動させることができ、したがって、必要なトランザクションを、プロセス間のトランザクションプロトコル（Transactional Protocol）の形式で移すことができる。

本発明の一実施の形態では、アプリケーション、例えば音声合成器は、プリエンプション（preemption）を許可するために割込、キューを禁止して、スワップアウトしなければならないときに、Ｉ／Ｏリソースの排他性を利用するＫＯＳを用いた特定のＣＰＵ上で、連続して、したがって絶え間なく動作することができる。他の実施の形態では、アプリケーションは、ＤＶＤフォーマットのビデオストリーミングであり、ビデオストリーミングは、中央のＯＳ（centralized OS）内のプロセス間で最適性を達成するために随時スワップアウトしなければならないシナリオに直面する中央のスケジューラ（centralized scheduler）に直面することなく、特定のＣＰＵ、メモリ及びＫＯＳを利用して動作することができる。

共有メモリ
共有メモリは、現在のＵＮＩＸ構造の非常に不可欠な部分であり、現在、特定の規則（particular convention）で使用するようになっているが、共有メモリは、また、ＫＯＳ、現在の規則の下に、分散ＯＳの目的で機能するように特定の方法で実装することができる。本発明の一実施の形態では、各オペレーティングシステムカーネルには、スケジューラが組み込まれており、スケジューラは、各カーネルの不可欠なキーコンポーネントプレーヤになっている。各分散オペレーティングシステムのＫＯＳは、ＫＯＳスケジューラになっている。４つのこのようなスケジューラを有する４つのこのようなオペレーティングシステムがある場合、各スケジューラは、他のオペレーティングシステムの他のスケジューラと通信するように設計されている。この通信は、他のスケジューラのリソースを共有できるように設計されている。各スケジューラは、リソースの特定のセットに接続（attached）されており、この特定のセットには、典型的なコンピュータリソース、例えばディスクアクセス、インターネットアクセス、映画ＤＶＤプレーヤ、音楽ＤＶＤ、キーボード通信等が含まれる。これらのリソースは、オペレーティングシステムのカーネルスケジューラの所定のセットに接続されており、スケジューラのそれぞれは、特定の所定の時点（specific given point）で、特別なリソースを必要とする特定の処理を、他のＣＰＵ上で動作している他のＫＯＳに外注又はオフロード（off-load）することができる。各スケジューラには、メモリの一部が割り当てられる。スケジューラ及びそのカーネルは、他のＫＯＳと共に、メインメモリ及びそれらのＣＰＵにマッピングされている。

ＴＣＰ／ＩＰプロトコル群（TCP/IP Protocol Suite）
ＴＣＰ／ＩＰローカル（TCP and IP local）は、データ及びアプリケーションファイルをＣＰＵとＫＯＳ間で転送するリソースとして用いることができる。各ＫＯＳは、それ自体のＣＰＵに局所的であり、独立したメモリがマッピングされたＩ／Ｏを有していてもよく、有していなくてもよい。一実施の形態では、多くのＵＮＩＸシステムに常駐しているＴＣＰポートのループバック機能（TCP Port loop-back facility）が用いられ、このＴＣＰポートのループバック機能は、ＫＯＳシステム構成の下に他のオペレーティングシステムとの間でデータファイルを送受信するように構成されている。

ＵＤＰプロトコルの機構（UDP Protocol Mechanics）
ユーザデータグラム（ＵＤＰ：User datagram）、ユーザ定義プロトコル（user defined protocol）は、ＴＣＰ／ＩＰプロトコル群の一部であり、ＫＯＳ規則の下に、独立したＣＰＵとオペレーティングシステム間でデータファイルをインポート及びエクスポートするように構成することができる。また、ＵＤＰは、独立したＣＰＵに常駐するオペレーティングシステム間でメッセージを受け渡すように構成することができる。

Ｉ／ＯＣＰＵベースのオペレーティングシステム
Ｉ／Ｏバスコントローラは、特殊用途のデバイスとして機能するが、また、ディスクの動作、あるいはメインメモリの入力又は出力用のチャンネルデータの処理に関係した特定のタスクに固有のタスクを指示する（directs）。このようなコントローラは、より機能的な能力を有し、常駐ソフトウェア、例えばＫＯＳが、ハードワイヤードな（hard wired）アプリケーションではなく、再構成可能なアプリケーションを特定のコントローラに提供することができる汎用のＣＰＵによって、容易に置き換えることができる。本発明の実施の形態において、Ｉ／ＯＣＰＵ又はプロセッサは、一般のシステムのＩ／Ｏ機能のみを処理するように特に設計されたスケジューラを有するＩ／Ｏオペレーティングシステムを常駐させる。これによって、バスデータは、ＣＰＵが必要条件としてＩ／Ｏキューを形成する能力を有するので、コントローラにおけるボトルネックを回避することができる。

表２は、特定のＫＯＳの種類と、各種類のＫＯＳがサポートするように特化された特定のリソースとを示している。例えば、表２は、メディアＯＳ（第１列の第５行）が、例えばＣＤ／ＤＶＤ（第４列の第５行）を動作させたときに、ビデオＩ／Ｏを実行するように特化されていることを、示している。同様に、表２は、ディスクＯＳ（第１列の第７行）が、例えばチャンネルバス（第２列の第７行）を介して通信するときに、ディスクＩ／Ｏを実行するように特化されていることを、示している。

本発明の一実施の形態では、オペレーティングシステムの機能が移動できるという概念（the concept of being portable）に基づく構成を用いており、オペレーティングシステムは、その機能を、それぞれが独立して動作するスレッドに分割することができる。この方法では、各スレッドは、異なる独立したスケジューラの下で、動作を他と関係なく実行する能力を有する。

状態遷移図に示す様々なプロセス状態は、状態間の可能な遷移が矢印によって示され、幾つかのプロセスは、メインメモリに記憶され、幾つかのプロセスは、２次（仮想）メモリに記憶される。

図３は、カーネルプロセススケジューリングの状態遷移２００を示す図である。この状態遷移２００は、「生成」状態（"Created" state）２０１と、「実行待ち」状態（"Waiting" state）２０７と、「実行」状態（"Running" state）２０５と、「ブロック」状態（"Blocked" state）２０９と、「スワップアウト及びブロック」状態（"Swapped out and blocked" state）２１３と、「スワップアウト及び実行待ち」状態（"Swapped out and waiting" state）２１１と、「終了」状態（"terminated" state）２０３とを含んでいる。これらの状態の詳細については後述する。

本発明の実施の形態は、複数のオペレーティングシステムを、互いに協調させて機能させるとともに、それらが管理するリソースによって特化され、したがって、実行待ち状態を、「受信された」外注又はアウトルーティングされたイベントを入力するキューとして用いることによって、「スワップアウト及び実行待ち状態」及び「スワップアウト及びブロック状態」の必要性を排除している。本発明の実施の形態では、分散する（to be deployed）マルチスレッディング、スワップアウト及び実行待ち／ブロックを、現在の設計とは異なる設計を行う機能として分散する能力を残している。

主要なプロセス状態（Primary process states）
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに「記憶」される。

生成（Created）（「新たな（new）」とも呼ばれる）
プロセスが最初に生成されたとき、プロセスは、「生成（created）」又は「新たな（new）」状態となる。この状態では、プロセスは、「実行可能（ready）」状態に入る（admission）のを待っている。この入力（admission）は、長期スケジューラ、すなわち入力スケジューラによって、承認又は遅延される。通常、殆どのデスクトップコンピュータシステムでは、この入力は、自動的に承認されるが、リアルタイムオペレーティングシステムでは、この入力は、遅延される場合がある。リアルタイムオペレーティングシステム（real-time operating system：ＲＴＯＳ）では、「実行可能」状態に余りにも多くのプロセスを入れると、過飽和になり、システムリソースの競合が始まり、結果として、プロセスのデッドラインに間に合わなくなることを避けることができなくなる。

実行可能（Ready）（「実行待ち（waiting）」又は「動作可能（runnable）」とも呼ばれる）
「実行可能」プロセス又は「実行待ち」プロセスは、既にメインメモリにロードされており、ＣＰＵ上で実行されるのを待っている（ディスパッチャ、すなわち短期スケジューラによって、ＣＰＵにコンテキストスイッチが起こる）。システムの実行のある時点において、「実行可能」プロセスが数多くある場合がある。例えば、シングルプロセッサシステムでは、同時に実行できるプロセスの数は１つだけであり、他の全ての「同時実行（concurrently executing）」プロセスは、実行されることを待っている。

動作（running）（「活動（active）」又は「実行（executing）」とも呼ばれる）
「動作（running）」プロセス、「実行（executing）」プロセス又は「活動（active）」プロセスは、現在ＣＰＵ上で実行されているプロセスである。この状態から、プロセスは、それに割り当てられたタイムスライスを超えると、オペレーティングシステムにより、コンテキストスイッチアウトされて、「実行可能」状態に戻される。なお、このプロセスは、完了又は終了され、あるいは幾つかの必要なリソース（例えば入出力リソース）によりブロックされて、「ブロック」状態に移行することもある。

ブロック（Blocked）（「スリープ（sleeping）」とも呼ばれる）
プロセスがリソース（例えばファイル、セマフォ又はデバイス）によって「ブロック」されると、そのプロセスは、ＣＰＵから除去されて、ブロック状態になる。プロセスは、そのリソースが利用可能になるまで、「ブロック」されたままであり、最悪の場合には、デッドロック（deadlock）とされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる（オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される）。一旦、オペレーティングシステムが、プロセスが最早ブロックされていないことを知ると、プロセスは、再び「実行可能」状態になり、この実行可能状態から「実行」状態にディスパッチされることが可能になる。実行状態になってから、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。

終了（Terminated）
プロセスは、「実行」状態から、その実行を完了させることによって、あるいは明示的に強制終了（kill）することによって、終了させることができる。何れの場合も、プロセスは、「終了」状態に移行する。この終了状態に入った後にも、プロセスがメモリから除去されない場合、このような状態は、「ゾンビ（zombie）」とも呼ばれる。

更なるプロセス状態（Additional process states）
仮想メモリをサポートしているシステムでは、更に２つのプロセス状態がある。これらのプロセス状態の両方において、プロセスは、２次メモリ（通常はハードディスク）に記憶される。

スワップアウト及び実行待ち（Swapped out and waiting）（「中断及び実行待ち（suspended and waiting）」とも呼ばれる）
仮想メモリをサポートしているシステムでは、プロセスは、スワップアウトすることができ、すなわち、プロセスは、中期スケジューラによって、メインメモリから除去されて仮想メモリに置かれる。そして、仮想メモリから、プロセスを、実行待ち状態にスワップバックすることができる。

スワップアウト及びブロック（Swapped out and blocked）（「中断及びブロック（suspended and blocked）」とも呼ばれる）
ブロックされているプロセスは、更に、スワップアウトされることもある。この事象（event）において、プロセスは、ブロックされた上にスワップアウトされており、スワップアウト及び実行待ちプロセスは、同じ状態にスワップバックすることができる（すなわち、この場合、プロセスは、ブロック状態に移行し、リソースが利用可能になるのを待っている）。

スケジューリング（Scheduling）
マルチタスクのカーネル（Ｌｉｎｕｘ等）では、複数のプロセスが常に存在することができ、各プロセスは、システム上でただ１つのプロセスであるかのように動作することができる。プロセスは、明示的に設計されない限り、他の如何なるプロセスも意識する必要はない。これにより、プログラムを容易に開発し、保守し、移植することができる。システム内の各ＣＰＵは、一度に、プロセス内の１つのスレッドしか実行することができないが、多くのプロセスからの多くのスレッドが同時に実行されているように見える。これは、スレッドが非常に短い時間動作するようにスケジューリングされ、そして、他のスレッドに動作の機会を与えるためである。カーネルのスケジューラは、スレッドのスケジューリングポリシを実施し、そこには、いつ、どれくらいの長さで、場合によっては（ＳＭＰシステム上の）どこでスレッドを実行できるかを含んでいる。通常、スケジューラは、それ自体のスレッドで動作し、このスレッドは、タイマ割込によって起動される。あるいは、このスレッドは、システムコール又はＣＰＵを明け渡すことを望む他のカーネルスレッドによって呼び出される。スレッドは、ある程度の時間実行することが許され、そして、スケジューラスレッドへのコンテキストスイッチが起こり、続いて、スケジューラが選択するスレッドへの他のコンテキストスイッチが行われる。このサイクルは、繰り返され、この方法では、ＣＰＵ使用のための特定のポリシが遂行される。

ＣＰＵバウンドなスレッド及びＩ／Ｏバウンドなスレッド（CPU- and I/O-bound Thread）
スレッドの実行は、ＣＰＵバウンドとＩ／Ｏバウンド（Input/Output bound）との何れかとなる傾向がある。すなわち、幾つかのスレッドは、計算を実行するために長い時間ＣＰＵを用い、他の幾つかのスレッドは、比較的遅いＩ／Ｏ動作を完了するために長い時間待機する。例えば、ＤＮＡ配列スレッド（thread sequencing DNA）は、ＣＰＵバウンドである。文書処理プログラム（word processing program）の入力を行うスレッドは、人間がタイプするのを待つために多くの時間を費やすので、Ｉ／Ｏバウンドである。スレッドがＣＰＵバウンドであるか、Ｉ／Ｏバウンドであるかは、常に明確でない。スケジューラが、何れのスレッドであるかを本当に考慮しても、スケジューラが行える最高のことは、推測することである。多くのスケジューラは、スレッドがＣＰＵバウンドとみなすべきか否か、Ｉ／Ｏバウンドとみなすべきか否かについて検討し、したがって、スレッドをどちらか一方に分類する技術は、スケジューラにとって重要な要素である。スケジューラは、ＣＰＵにアクセスする優先権を、Ｉ／Ｏバウンドなスレッドに与える傾向がある。人間の入力を行うプログラムは、Ｉ／Ｏバウンドな傾向があり、最も速いタイピストであっても、各キーストローク間にかなりの時間がかかり、タイピストがインタラクトするプログラムは、この間は単に待っているだけである。人間が速やかな応答を期待してる場合、速度及び応答が遅いと、それに気付かれるので、人間とインタラクトするプログラムに優先度を与えることが重要である。

ラウンドロビンスケジューリングアルゴリズム（Round-Robin Scheduling Algorithm）
スケジューリングは、タスクに一連のリソースを割り当てるプロセスである。スケジューリングは、多くの分野、例えば計算プロセス及び生産プロセスにおいて、重要な概念である。

スケジューリングは、マルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプトである。スケジューリングは、優先順位付きキューの優先度をプロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。

汎用オペレーティングシステムでは、スケジューラの目的は、プロセッサの負荷をバランスさせ、何れか１つのプロセスが、プロセッサを独占し、且つリソースに飢餓することを防止することである。リアルタイム環境、例えば産業界における（例えばロボティクス用の）自動制御機器では、また、スケジューラは、プロセスがデッドラインに間に合うことができるように保証しなければならない。これは、システムを安定に保つためには重要である。

ラウンドロビン方式は、オペレーティングシステムにおけるプロセスのための最も簡単なスケジューリングアルゴリズムである。このアルゴリズムは、各プロセスに、タイムスライスを同じ長さで、順番に割り当てて、全てのプロセスが同じ優先度を有するように処理する。優先順位付きスケジューリング方式（prioritized scheduling system）では、優先度が等しいプロセスは、多くの場合、ラウンドロビン方式でアドレッシングされる。このアルゴリズムは、プロセス記述子ブロック（Process Descriptor Block：ＰＤＢ）のリストの最初から開始して、タイムスライスが利用可能になったときに、ＣＰＵの機会を各アプリケーションに順番に与える。

ラウンドロビンスケジューリングは、ソフトウェアで実装することが簡単であるという優れた利点がある。オペレーティングシステムは、リストの最初に対する参照及び現アプリケーションに対する参照を有しなければならないので、次の要素に対するＰＤＢの配置又はチェイン（array or chain）に続いて、次に何を動作すべきかを容易に決定することができる。一旦、配置の最後に到達すると、選択は、配置の最初に戻される。ブロックされたアプリケーションは、ＣＰＵ時間を不必要に浪費し、更に悪いことには、実際にはもう少し待たなければならないときに、タスクに、そのリソースを見つけたと思わせるので、このブロックされたアプリケーションが不注意に選択されないことを保証するために、ＰＤＢを調べなければならない。「ラウンドロビン」という用語は、各個人が順番に何かを平等に分け合うという他の分野で知られているラウンドロビンの原理に由来している。

簡潔に言えば、各プロセスには、そのカンタム（quantum）と呼ばれる時間間隔が割り当てられ、この時間中、プロセスは、動作することができる。カンタムの終了後に、プロセスがまだ動作している場合、ＣＰＵは、プリエンプトされて、他のプロセスに与えられる。カンタムが経過する前に、プロセスがブロックされ、又は終了した場合、プロセスがブロックされたときに、ＣＰＵの切換が行われる。

スケジューリングアルゴリズムは、クロック割込をどのように処理するかについて、２つのカテゴリに分割することができる。

ノンプリエンプティブスケジューリング（Nonpreemptive Scheduling）
一旦、プロセスにＣＰＵが与えられ、そのプロセスがＣＰＵを持ち続ける場合は、スケジューリング規則は、ノンプリエンプティブである。ノンプリエンプティブスケジューリングの幾つかの特徴を以下に記す。

１．ノンプリエンプティブ方式では、短いジョブは、より長いジョブによって待たされるが、全てのプロセスの全体的な処理は公平である。

２．ノンプリエンプティブ方式では、入力最優先ジョブは、待っているジョブを移動することができないので、応答時間は予測しやすい。

３．ノンプリエンプティブスケジューリングでは、スケジューラは、以下の２つの局面でジョブを実行する。
ａ．プロセスが実行状態から実行待ち状態に切り換わったとき
ｂ．プロセスが終了したとき

プリエンプティブスケジューリング（Preemptive Scheduling）
一旦、プロセスにＣＰＵを与えられても、ＣＰＵが取り上げられる可能性がある場合、スケジューリング規則は、プリエンプティブである。論理的には動作可能なプロセスを一時的に停止することを許可する戦略（strategy）は、プリエンプティブスケジューリングと呼ばれ、完了するまで動作させる（run to completion）方法と対照的である。

ラウンドロビンスケジューリングは、（タイムスライスの最後では）プリエンプティブであり、したがって、システムが、対話型利用者（interactive users）に対して妥当な応答時間を保証する必要がある時分割環境（time-sharing environments）においては、有効である。

ラウンドロビン方式において、最も注目される問題は、カンタムの長さである。カンタムを余りにも短く設定すると、余りにも多くのコンテキストスイッチが起こり、ＣＰＵ効率が下がる。一方、カンタムを余りにも長く設定すると、応答時間が遅くなり、先着順サービス（First Come First Served：ＦＣＦＳ）に近づく。この具体例を以下に示す。

タスク切換が２ｍｓであると仮定する。カンタムが８ｍｓである場合、非常に優れた応答時間を保証することができる。この具体例では、２０人のユーザが全て、シングルＣＰＵのサーバにログインしており、全てのユーザが同時に要求を生成する。各タスクは、１０ｍｓ間（８ｍｓのカンタム＋２ｍｓのオーバヘッド）かかり、２０番目のユーザは、２００ｍｓ（１０ｍｓ×２０）、すなわち１／５ｓで応答を得る。

一方、効率は、以下の通りである。
有効時間の総時間＝８ｍｓ／ｌ０ｍｓ＝８０％、すなわち、ＣＰＵ時間の２０％がオーバヘッドに浪費されている。

２００ｍｓのカンタムでは、効率は、２００ｍｓ／２０２ｍｓ＝約９９％である。

しかしながら、応答時間については、２０人のユーザが同時に要求を行った場合、２０２×２０＝４０４０ｍｓ、すなわち４ｓ以上となり、これは好ましくない。実際に起こっていることの全体像を得るために、パラメータを定義する。
・応答時間−プロセスが完了する時間。ＯＳは、ある種のプロセスを好み、又は平均待ち時間のような統計的特性を最小にすることを望む。
・実行時間（Implementation Time）−これは、アルゴリズム及び保守の複雑性を含む。
・オーバヘッド−どのプロセスをスケジューリングするかを決定し、この選択のために必要とされるデータを収集する時間。
・公平性−ユーザプロセスを異なって処理する程度の差。

したがって、カンタムを長くすると、効率が良くなることを保証し、カンタムを短くすると、応答時間が短くなることを保証する。スループット及びターンアラウンド（turnaround）は、システム内のジョブの数及び１タスク当たりのＩ／Ｏの使用量に依存する。ラウンドロビン方式は、明らかに公平である。

いずれにしても、ラウンドロビンスケジューリングの下での平均待ち時間は、多くの場合、非常に長く、プロセスは、そのタイムスライスよりも短い時間を使用する場合がある（例えば、セマフォ又はＩ／Ｏ動作のブロッキング）。アイドルタスクは、動作している他のタスクがないとき以外は、決してＣＰＵを獲得してはならない（アイドルタスクは、ラウンドロビンに参加してはならない）。

最新の主要なオペレーティングシステムは、ラウンドロビンの変形で動作し、これらがもたらす最も重要な改良は、プロセスの優先順位クラス（priority classes）である。

これらのクラスを設定する簡単なアルゴリズムは、最後のカンタムのうちのプロセスが使用した割合（fraction）をｆとすると、優先度を１／ｆに設定することである。その１００ｍｓのうちの２ｍｓだけを使用したプロセスは、優先度（priority level）が５０となり、ブロッキングの前に５０ｍｓを使用したプロセスは、優先度が２となる。したがって、１００ｍｓのカンタム全体を使用したプロセスは、最下位優先度になる（優先度を１〜９９に設定するＬｉｎｕｘとは異なり、優先度がＣ−スタイル［０・・・９９］である他のシステムでは、１になる）。

ＫＯＳスケジューラのオペレーティングシステムの設計には、明らかに３つの構成がある。図１は、他の全ての従来のオペレーティングシステムと同様に、リソースが外側の周辺に沿って分布するクローズクラスタＫＯＳ構成（close cluster KOS configuration）を示している。

図４は、ＫＯＳ概念設計の下で可能である幾つかの追加機能を有するシステム３００を示している。これらの追加機能には、入力機構からのイベントを受信して、イベントを、リソースへのアクセスを得る適切な配信ＯＳ（distribution OS）にルーティングする目的だけに専用の中央に位置するルーティングＯＳ機能（central routing OS facility）３０１が含まれる。この設計の下では、各オペレーティングシステム３１０〜３１６は、それに割り当てられた各イベントの完全な解決（full resolution）を得るために直ちに達することができるそのメモリ使用量（footprint）内に組み込まれた限られた数のリソースを有する。外側の周辺には、システムリソースとみなすことができる更なるリソースがあり、内部の各ＯＳ３１０〜３１６は、これらのリソースを、共有しなければならないが、拡張イベント（完了のためにリソースを拡張する必要があるジョブ）のために確保することができる。

また、図４に示すように、システム３００は、ＯＳ機能３０１を取り囲む複数のオペレーティングシステム３１０〜３１６を備える。図４では、オペレーティングシステム３１０〜３１６は、リソース３３０の外殻によって囲まれており、次に、リソース３３０は、アプリケーション３４０の外殻によって囲まれている。

カーネル動作スケジューラの構成の１つの方法は、スター構成（Star Configuration）である。スター構成の下では、１つのカーネルが中央のディスパッチャ（central dispatcher）として機能するように構成されており、実行可能状態からプロセスを受信する役割は、必要なリソース、例えば追加的なメモリ割当、スタック要求、ロバストなＩ／Ｏトラヒック等のためにプロセスをスクリーニングし、このプロセスを、このような要求をサポートするように構成された適切なオペレーティングシステム環境にディスパッチすることである。スター構成の下では、如何なるプロセスもブロック、すなわちスリープされず、トラヒックは、実行状態、実行待ち状態及び切換状態（switched state）のみの３つの状態を用いて流れる。

システムＳ_１内のスターコアカーネル構成（Star Core Kernel Configuration）
コアとして機能するカーネルは、ｎ個の他のカーネルによって囲まれている。図５は、本発明の一実施の形態に基づくシステムＳ_１内のスターコアカーネル構成３５０を示している。このスターコアカーネル構成３５０は、ＫＯＳを有する中央ルーティングオペレーティングシステム（Central Routing Operating System）３６０を備え、この中央ルーティングオペレーティングシステム３６０は、カーネルオペレーティングシステム（kernel operating system）３５１〜３５６によって囲まれており、これらのカーネルオペレーティングシステム３５１〜３５６は、アプリケーション３６３の外殻によって囲まれている。各オペレーティングシステム３５１〜３５６を囲む外殻は、各オペレーティングシステム３５１〜３５６が利用可能なリソースに対応している。中央ルーティングオペレーティングシステム３６０は、以下の典型的なプロセス状態を取る。

１．システムＳ_１内でプロセスが最初に生成されたとき、プロセスは、それが必要なリソースのためにスクリーニングされる新たなプロセス状態（new process state）となる（システムリソースに関する章参照）。一旦、必要なリソースが決定されると、コアは、これらのリソース条件（resource requirement）を満たしそうな、例えばＩ／Ｏオペレーティングシステム（Ｉ／Ｏオペレーティングシステム参照）のようなオペレーティングシステム（理想的にはアイドル状態にある）を調べる。一旦、適切なＯＳが決定されると、プロセスは、（通常、実行可能状態から）切換状態に移行し、クロックの次のサイクルで、プロセスは、システムＳ_１内の適切なオペレーティングシステムにディスパッチされる。

２．コアは、既にディスパッチされて、現在動作中であるべきプロセスに基づいて、他の全ての実行状態と通信するために使用される「実行状態」を有する。コアの実行状態は、実際にはプロセスを動作させないが、システムＳ_１内の全ての実行プロセス（running processes）の経過を追跡して、各状態をコンソールに通知する像通信状態（statue communication state）又は仮想実行状態である。

３．まさに生成されたプロセスの実行可能状態は、優先順位の決定状態（triage state）又はスクリーニング状態（screening state）として機能するスターコアカーネルの下にある状態であり、スターコアカーネルの下にある周辺カーネル（peripheral kernel）の何れにおいても、周辺カーネルは、従来のプロセス状態の下にあるのと同様に、実行待ち状態又は動作可能状態（runnable state）として機能する。

図６は、通信チャンネルＣ６８０を介して通信する複数のカーネル６０１、６３０、６４０のハイレベルのブロック図であり、各カーネルは、スイッチアウトするアプリケーションプログラムＡと、スイッチインするアプリケーションプログラムＢとを有する。例えば、カーネル６０１は、中央演算処理装置６０２によって実行され、スケジューラ６０７を含み、ＫＯＳ６１０は、実行状態６１１と、実行待ち状態６１２と、アプリケーションプログラムＡ６１５を切り換える切換状態６１３とを有する。図６は、スイッチアウトするアプリケーションＡ６１５と、スイッチインするアプリケーションＢ６０５とを示している。カーネル６３０、６４０は、カーネル６０１と同様に動作するので、これ以上は説明しない。通信チャンネルＣ６８０は、複数のＣＰＵに亘って、カーネル６０１、６３０、６４０の内部のＫＯＳスケジューラ間を結んでいる。

共有メモリ（Shared Memory）
図７は、共有メモリΣ_１７２０、Σ_２７２１、Σ_３７２２、Σ_４７２３と、オペレーティングシステム７１０〜７１３の環境とを含むシステム７００を示している。図７に示すように、共有メモリΣ_１７２０〜Σ_４７２３は、まさに、ＵＮＩＸオペレーティングシステムの一部であり、抽象化（abstract）は、現在、特定の規則で使用するように提供されているが、共有メモリΣ_１７２０〜Σ_４７２３は、本発明の実施の形態に基づく分散オペレーティングシステムの目的を果たすように、特定の方法で実装することができる。各オペレーティングシステムカーネルが専用のスケジューラとなり、これらの専用のスケジューラを有する４つのこのようなオペレーティングシステム７１０〜７１３がある場合、各スケジューラが他のスケジューラのリソースを共有することができるという方法によって、他のスケジューラと通信するように、スケジューラは設計されている。各スケジューラは、初期化（起動）のときに、他のスケジューラに知られている特定のリソースに接続する（attached）場合、その動作の任意の時点で、それが供給するリソースのカテゴリの一部でない動作を、他のスケジューラに外注することができる。

各スケジューラには、メモリの、他のスケジューラと共有する一部が割り当てられており、完了するためにアクセスして処理するデータセットによって動作するプログラムを必要とする動作を、他のスケジューラに外注する場合、外注スケジューラは、量があるデータ自体ではなく、ポインタ及びファイル記述子だけを受信スケジューラに渡す。ポインタ及びファイル記述子は、そのＣＰＵで処理する受信スケジューラ上のキューに入れることができる。

ＩＰＣ機能及びプロトコルスタック（IPC Facilities and Protocol Stacks）
プロトコルスタックだけでなく、ＩＰＣ機能も、ＵＮＩＸ構造とは別に設けられており、これらの両方は、既にユーティリティとして統合されている。また、これらのユーティリティは本発明にも有用である。これらのユーティリティは、幾つかのプラットフォームに亘ってではなく、特定のコンピュータシステムに組み込む現在の分散コンピューティングを除いて、クラスタ内のオペレーティングシステム間で通信を大量に行うように意図された形で構成することができる。

ＩＰＣスケジューラ（IPC Scheduler）
図８は、ネットワークコントローラを１つのリソースとして示しており、データパケット７５１がネットワークオペレーティングシステム（network operating system：ＮＯＳ）７５５に送信されている。図８に示すように、カーネルスケジューラは、リソースプロセスを確保する（acquisition）フィルタを備え、カーネルスケジューラは、まず、プロセスがどこで発生すべきかを判定するために必要とされるリソースを選択する。各ＣＰＵは、汎用ＣＰＵであり、各オペレーティングシステムのカーネルは、リソースのグループ又はセットの割当に、より特化又は専用とされる。図８は、本発明に基づいて用いられる、特化又は専用とされたオペレーティングシステムの一実施の形態を示している。ＮＯＳ７５５は、ＦＴＰ、ＰＰＰ、Ｍｏｄｅｍ、Ａｉｒｐｏｒｔ、ＴＣＰ／ＩＰ、ＮＦＳ及びＡｐｐｌｅｔａｌｋ等のプロトコルのうちの１つ以上を用いることができ、また、プロキシのオプション（Proxy options）によって、ポートを用いることができる。

なお、メモリは、４つ（quadrant）に分割され、メモリの一部は、各オペレーティングシステム間で分割され、ポインタ及びファイル記述子は、大量のデータを移動するのではなく、割当によってオペレーティングシステムからオペレーティングシステムに渡すことができることは、明らかである。ＩＰＣ機能を用いることにより、プロセスは、必要なトランザクションを運ぶためのメッセージを、トランザクションプロトコルの形式で通信することができる。

一実施の形態においては、アプリケーション、例えば音声合成器は、プロセスを中断する割込なしで、特定のＩ／ＯＯＳを利用するＣＰＵ上で連続して動作することができる。他の実施の形態においては、アプリケーション、例えばビデオストリームは、特定のＣＰＵと、メモリと、プログラムをその寿命中にスワップイン及びスワップアウトするスケジューラによって制御されることがないＯＳとを利用して、動作することができる。

図９は、本発明の一実施の形態に基づくＫＯＳ７９０を示しており、ＫＯＳ７９０は、プロセスを、Ｉ／Ｏキー７８１と、ＡＯＳサウンドシステム７８２と、Ｉ／Ｏビデオ７８３と、Ｉ／Ｏディスク７８４と、Ｉ／Ｏユニバーサルシリアルバス（ＵＳＢ）７８５と、Ｉ／Ｏ補助ポート７８６と、プリントＯＳ７８７と、Ｉ／Ｏネットコントローラ７８８とに割り当てるために用いられる。図９に示すように、Ｉ／ＯＵＳＢバス７８５は、コントローラを有し、コントローラは、そのバス上のリソースのマネージャである。リソースは、データをバスに沿って双方向に移動させるために必要である。Ｉ／Ｏは、あらゆるコンピュータの主要な機能であるので、最早オペレーティングシステムの副機能ではない。本発明の実施の形態では、オペレーティングシステムは、非同期だけではなく、並列して動作する複数の下位のオペレーティングシステムを調整する。

Ｉ／Ｏオペレーティングシステム
Ｉ／Ｏオペレーティングシステムは、集中化された非同期中央ＯＳ（centralized asynchronous central OS）からのデータ読出を実行して、何時、どのようにデータを転送するかを決定するコントローラ機能を実行する。

本発明に基づく構成（construct）は、スレッドに分割されたその機能を有することができる、移動可能（portable）であるという概念に基づくオペレーティングシステムの機能に分散され、そこでは、スレッドは、プロセスに類似しているが、他のスレッドコード（threads code）、データ及び他のリソースを共有することができる。

図１０に示す一実施の形態における構成（construct）は、１つのオペレーティングシステムの機能８０１、８０３、８０５、８０７、８１２、８１４を分散し（deploy）、システムコールの全ては、スレッディングされた通信（threaded communication）を用いて互いに動作する非同期オペレーティングシステム（asynchronous operating system）８１０、８１６を形成する。それ自体の独立したカーネルを有する各オペレーティングシステムは、２つの特化された機能及びキュー管理のために特別に設計されている。この構成（arrangement）は、全てのタスクをコンピュータの回りに分散させることによって、サイクルタイムを分割し、複数のＣＰＵを利用する。各カーネルは、それぞれ１つのＣＰＵに結び付けられており、コントローラは、ＣＰＵ又は特殊用途のコントローラによって置換される。

主要なＫＯＳプロセス状態（Primary KOS process states）
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに記憶される。

生成（「新たな」とも呼ばれる）
アプリケーションが開かれて、プロセスが最初に生成されたとき、プロセスは、「生成（created）」又は「新たな（new）」状態となる。このアプリケーション状態では、プロセスは、「実行可能（ready）」状態に入るのを待っている。この入力は、長期スケジューラ、すなわち入力スケジューラ、ＫＯＳスケジューラによって、承認又は遅延される。入力する間に、プロセスは、必要とされるリソースが調べられた後、実行状態に入り、あるいは、プロセスは、動作に必要とされる適切なリソースを有する他のＣＰＵのオペレーティングシステムに切り換えられる切換状態に再設定される。

実行可能（実行待ち）
この実行可能状態は、上述した主要なプロセス状態の「実行可能」状態と同様である。

動作（Running）
この動作状態は、上述した主要なプロセス状態の「動作」状態と同様である。

切換（以前は「ブロック」又は「スリープ（sleeping）」と呼ばれていた）
プロセスがリソース（例えばファイル、セマフォ又はデバイス）によって「ブロック」されるのではなく、（ブロックプロセスは、実行を続けることができないので）、プロセスは、現在のＣＰＵ及びオペレーティングシステムから除去されて、ブロック状態になり、プロセスが必要とするリソースが連続して利用可能な他のＣＰＵ及びオペレーティングシステムに移される。シングルＣＰＵ／シングルＯＳのシナリオの下では、プロセスは、そのリソースが利用可能になるまで、ブロックされたままであり、最悪の場合には、デッドロックされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる（オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される）。一旦、プロセスが、そのリソースが利用可能な適切なオペレーティングシステムに到着すると、プロセスは、再び「実行可能」状態に入り、この「実行可能」状態からその「実行」状態にディスパッチされ、この「実行」状態から、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。

終了（Terminated）
この終了状態は、上述した主要なプロセス状態の「終了」状態と同様である。

更なるプロセス状態（Additional process states）
仮想メモリをサポートしているシステムでは、更に２つのプロセス状態がある。これらの状態の両方において、プロセスは、２次メモリ（通常はハードディスク）に記憶される。

スワップアウト及び実行待ち（Swapped out and waiting）
このスワップアウト及び実行待ち状態は、上述した主要なプロセス状態の「スワップアウト及び実行待ち」状態と同様である。

スワップアウト及びブロック（Swapped out and blocked）
このスワップアウト及びブロック状態は、上述した主要なプロセス状態の「スワップアウト及びブロック」状態と同様である。

図１１は、通知可能なプロトコル（signaling enabled protocols）を示している。例えば、プロトコルＫ_Ｃは、複数のカーネル、すなわちＫ_{ＤＩＳＰＬＡＹ}８５２と、Ｋ_{Ｉ／ＯＦｉｌｅ Ｓｙｓｔｅｍ１}８５３と、Ｋ_{ＡＰＰＳ１}８５４と、Ｋ_{ＣＯＮＴＲＯＬ}８５５と、Ｋ_{ＢＵＳ ＣＯＮＴＲＯＬ}８５６とを同期させるのに用いることができる。非同期で機能する３つ以上のカーネルを、動作環境において中央及びコアのカーネルによって同期させる方法について説明する。ＵＮＩＸオペレーティングシステムは、通常カーネルとして知られているコアからなり、カーネルは、中央コマンド（central commands）の全てを実行し、動作を実行するあるタスクを実行する複数の処理又はノードを、動作環境に亘って分散する。ここに説明する方法は、これとは異なり、まず、中央のコアカーネル（central core kernel）が、全ての入力及び出力動作の大部分をＩ／Ｏカーネルに外注できるようにし、次に、Ｉ／Ｏカーネルは、中央のカーネル（central kernel）又はコアに更なる負担をかけることなく、このような動作の残り部分を実行する。

オペレーティングシステム内では、ファイルＩ／Ｏ、すなわちメモリへ／からのデータ転送が、従来のカーネルの大部分の動作を占め、このような負荷が大きいタスクから従来のカーネルを解放することができるとき、カーネルによって実行されるＩ／Ｏ動作、例えばアプリケーションの管理並びにコマンドの解釈、及び他のコア構成、例えば特定のＣＰＵ上での処理時間のスケジューリングは、より少ない待ち時間で完了することができる。

この方法は、中央の階層的カーネルと、幾つかの下位の及び／又は非同期カーネルとの動作間のタスク分離を記述している。対称カーネル（symmetric kernel）が共有情報を非同期で処理する対称カーネル処理環境では、このような環境の不一致の下で起こり得る衝突を制御し、指示する環境変数（environmental variable）を用いている。また、この方法は、対称的、抽象的、且つ車輪のような装置（symmetric metaphysical wheel-like apparatus）上の複数の回転カーネル（rotating kernel）を記述しており、全ての回転カーネルは、カーネルとそれが動作するコマンド及びデータ間の衝突を制御するために用いる環境変数を介して、情報を共有している。

通信プロトコル（COMMUNICATION PROTOCOL）
本発明の実施の形態においては、通信プロトコルは、環境の下で動作するカーネル間の通信及びこれらのカーネルの下で動作するプロセス間の通信プロトコルとして定義される。この通信プロトコルにより、３つ以上のプロセスが存在することができ、アドレッシングする特定の種類の通信の外部にあるプロセスによって管理される通信によって、これらのプロセス間で同時に通信することができる。通信プロトコルは、構成アーキテクチャ（configuration architecture）の種類に応じて、異なった設計を行うことができる。

プロセスは、プロセス間の通信のテーブルの代わりに、通信ポートに並ぶ（line up）。図１２に示すように、プロセス９１１〜９１６の全ては、通信ポート９１０にアクセスしようとしている。プロセスマネージャは、プロセス間の通信を、要求及びリソースが解放されるとして、管理する。標準のＩＰＣテーブル構成（standard IPC table configuration）に比べて、このポートのような通信プロセスによって提供される多くの利点のうちの１つは、２つ以上のプロセスが同時に通信できるということである。他の利点は、ハンドシェークという抽象概念（handshake abstract）ではなく、プロセス間のプロトコルによって全ての通信が管理されるということである。６つ以上のプロセスが互いの間の通信を確立するために並ぶとき、各プロセスは、それ自体と、１つ以上の他のプロセスとの間のダイレクトライン（direct line）を確立しなければならない。

例えば、図１２において、プロセス９１１は、リソースＡを解放しようとしており、プロセス９１２は、リソースＡを要求しようとしている。通信は、プロセス９１１とプロセス９１２間で確立され、これによって、プロセス９１１、９１２は、リソースＡに関する共有関係（shared relationship）を有し、リソースＡは、２つのプロセス９１１、９１２間の通信を行うプロセスマネージャによって管理される。プロセス９１１及びプロセス９１２の両方が、所定のシナリオの下でリソースＣを要求する場合であって、プロセス９１１がリソースＣを要求しながら、リソースＡを解放し、プロセス９１５がリソースＣの解放に至っていない場合、プロセス９１２の要求は、プロセス９１１がリソースＣを入手し、これを解放するまで、ブロックされる。この所定のシナリオは、リソースを要求しているプロセスが多くあり、利用可能なリソースが適切な数よりも少ないという事実によって支配されている。

以下に説明するマネージャは、以下に限定されるものではないが、関係マネージャ、プロセッサマネージャ（Processor Manager）、スレッドマネージャ（Thread Manager）、リソースマネージャ及びリソース割当マネージャ（Resource Allocation manager）を含み、これらは全て、本発明に基づくＫＯＳの実施の形態に使用される。以下では、これらのマネージャ及びＫＯＳの他のコンポーネントがどのように機能するかを説明する。

関係マネージャ（RELATIONSHIP MANAGER）
関係マネージャは、常に、環境内で動作する複数のカーネル間の関係を管理する。各カーネルによって、多くの所定のスレッドがそれらのカーネルコードを実行する役割を果たすことができるが、この要素は、関係マネージャによって実行されるタスクには関係ない。本発明の実施の形態に基づく関係マネージャによって実行されるタスクは、カーネルと、カーネル間の互いの関係とを含むものである。

各関係マネージャは、構成の種類に応じて、ある確立されたプロトコルを用いて通信を行い、リングオニオンカーネルシステム（Ring-Onion Kernel System）内で又は４つの構成アーキテクチャのそれぞれ内のオペレーティングシステムに亘って組織化されたカーネル間で情報を共有する。図１３は、リソースマネージャ９２１と、リソース割当マネージャ９２２とを示している。図１３において、リソース共有（Resource Sharing）と呼ばれるプロトコル｛Ａｌ｝は、環境内に常駐するあるリソースの知識（knowledge）を要求する関係マネージャから送信するデータのプロトコルを表している。この図１３の同じリソースマネージャ９２１の下の｛Ｂｌ｝は、全く同じプロトコルの他の層を表しており、解放されたリソース又はリソースが解放されるまでの見積時間に関する情報を通知する。第３のパラメータ及びプロトコル層である｛Ｃｌ｝は、要求されたリソース、解放されたリソース、又はあるリソースがどこに常駐するかに関する、受信する情報を表している。

他の具体例では、関係マネージャＲＭ１は、関係マネージャＲＭ２の下のリソースＡｌに関する要求を生成する。関係マネージャＲＭ２が、リソースＡｌが使用中であることを知っている場合、関係マネージャＲＭ２は、そのリソースマネージャＲｓＭｇｒ２の要求を生成し、したがって、階層プロトコル（layered protocols）のシステムを介して、要求の元に情報を送り返すことによって、リソースＡ１が解放されるまでの時間を見積もることができる。

関係マネージャＲＭ１は、一旦リソースＡ１が解放されたことを知ると、例えば特定のプロトコル層を用いて、関係マネージャＲＭ３に知らせる。関係マネージャＲＭ３は、そのカーネル又はそのカーネルのスレッドの１つがリソースＡ１を獲得したことを知ると直ちに、リングアーキテクチャ（ring architecture）の下では、環境内の動作している全てのカーネル又はオペレーティングシステムのリソース割当マネージャに、スター−中央アーキテクチャ（Star-Center architecture）の下では、コマンド制御オペレーティングシステム又はカーネルのみに知らせる。

タスク分散のための構成（Configurations For Task Distribution）
全てのカーネルに常駐するスケジューラは、タスクをどのように分散させて実行するかを決定する中心的役割を果たすが、これらのスケジューラは、本発明にとっても重要であり、動作をどのような流れで実行するかを決定する中心的役割を果たす。本発明の実施の形態では、環境に割り当てられたタスクを実行する４種類以上の構成があり、これらの構成は、環境の中央コマンド構造であると考えられ、以下のように命名される。

アーキテクチャ（ARCHITECTURES）
１．階層構造（Hierarchical Structure）
本発明に基づき、環境内で複数のカーネルが同時に動作する階層構造では、ホストカーネル（host kernel）は、全ての制御の中心にあり、環境によって実行する全ての入力ジョブ又はタスクを受信する。コマンドカーネル（Command kernel）は、必要とされるリソースのタスクをスクリーニングし、特定のタスクを、このタスクが完了まで実行される適切なカーネルに割り当てる。コマンドカーネルの下には、関係マネージャがあり、関係マネージャは、コマンドカーネルと、環境内で動作する後続のカーネルとの間の関係を管理する。関係マネージャは、上述した１つと同様の制御プロトコル構造（control protocol structure）によって、他のカーネルを管理する。関係マネージャは、環境内で動作する他のカーネルのそれぞれとの間のリソース要求（resource requests）及びリソース条件を、記録して、バランスさせる。この仕事（chore）を実行するために、関係マネージャは、全てのタスク及びジョブが最初にどこに割り当てられたか、及びこれらが特定のカーネルに割り当てられた理由を理解する必要がある。階層構造の下では、環境にインストールされたリソースは、特定のカーネルに割り当てられ、例えば、プリンタは、特定のカーネルに割り当てられ、ビデオ画面（video screen）は、他のカーネルに割り当てられる。特定のＩ／Ｏ駆動タスク（I/O driven task）を必要とするタスクは、特定のリソースを獲得する際の遅延のために、ビデオ／オーディオ駆動タスク（video/audio driven task）に割り込まない。

２．ラウンドロビン（Round-Robin）
ラウンドロビン構成（Round-Robin configuration）は、所定の順序でカーネルに割り当てるタスクからなる。この場合、カーネルが、タスクを実行するために必要とされるリソースを含んでいない場合、関係マネージャは、そのタスクを次のカーネルに適切に転送する役割を果たす。本発明では、ラウンドロビン構成は、多くの異なるよくある状況に適しているが、他の状況では、本発明が意図する好ましい効果（benefits）が得られないこともある。

ラウンドロビン構成の下では、各カーネルは、環境内で、他のカーネルに対して非同期で動作し、関係マネージャによってリンクされ、したがって、カーネルは、各カーネルのそれぞれの下の各リソースマネージャと通信を行う。ラウンドロビン構成は、制御の中心点を有していない。この構成の場合、コマンドカーネルは存在しない。各カーネルは、抽象的環状構成（abstract circular configuration）にあるとみなされ、それぞれの関係マネージャを介して、他のカーネルに接続する。

３．先入先出（First-in First-Out：ＦＩＦＯ）
ＦＩＦＯ構成の下では、各カーネルは、環境に現れる各タスクを先着順に実行する。特定のタスクがカーネルに供給され、カーネルがその所定のタスクを受け入れるために十分に解放されている場合、タスクがリソースのためにブロックされるまでは、タスクは、そのカーネルに常駐する。

４．スター−中央（Star-Center）
スター−中央アーキテクチャは、中央コマンドカーネル（central command kernel）を環状に取り囲む複数のカーネルを有する構成として定義される。中央コマンドカーネルは、制御カーネル（controlling kernel）であり、その機能を用いて、スター構成（Star configuration）の下の他のカーネルのためのタスク要求を受信して、組織化する。スター−中央構成（Star-Center configuration）は、環境内のリソースに基づいて、下位のカーネルを星座（constellation）にグループ化する。ここで、所定のタスクが所定のリソースを用いることを必要とし、一方、他のタスクが、多くの場合、所定のタスクが所定のリソースを用いることを完了するまで、その所定のリソースによってブロックされるオペレーティングシステムについて検討する。本発明では、カーネルスレッドは、このようなボトルネックを解消する際に、特定のカーネルをコピーするように専用とされ、これに対して、他のカーネルは、それらのスレッドを適宜用いることができる。複数のオペレーティングシステムのための多くの条件のうちの１つは、専用のカーネルが、特定の種類の複数の接続された（attached）リソースを処理するそれらのコードのコピーをスレッドアウト（thread out）する能力を用いる特定のリソースを処理することができるようにすることであり、したがって、複数のカーネルは、複数のＣＰＵ上で動作するだけではなく、複数のＣＰＵに亘るそれら自体の複数のコピーを動作させる。

５．リングオニオンカーネルシステム（Ring-Onion Kernel System）
リングオニオンカーネルシステムでは、複数のストリップダウンカーネル（strip-down kernel）は、オペレーティングシステムのサービス構造内で同時に機能する。オペレーティングシステムのサービス構造とは、サービスの特定のオペレーティングシステムのセットを構成する全ての補助的及び予備的ファイル（ancillary and auxiliary files）を意味する。これらのサービスは、共有することができる。このアーキテクチャ、例えばシステムコール機能及びカーネルコードの外部の他の機構の下では、設計の多様性を与え、特定の必要条件下の性能に影響を与えることができる。リングオニオンカーネルシステムの場合には、カーネルの全ては、シングルオペレーティングシステムカーネルのタスクを実行するが、これらのタスクを互いに非同期で実行し、補助的なファイル及び機能を共有するときには、これらのタスクを別々のＣＰＵ上で実行する。

上述した図１は、カーネルのシステムが、同じサービス及び機能を共有するが、タスクを非同期で実行するリングオニオンカーネルシステムを示している。各カーネルは、その局所的な空間内に即時の（immediate）サービス機能のセットを有しているが、より広いサービスは、環境内の全てのカーネル間で共有される。

図１は、全てのカーネルが、コマンド及び制御カーネルなしで、互いに非同期に動作することを示しているが、本発明に基づくアーキテクチャでは、コマンド及び制御カーネルをインストールすることができ、これにより、スター−中央システムアーキテクチャと同様の仕様を、リングオニオンアーキテクチャと協調させて適用することができる。

マルチプロセッサの同期（MULTI PROCESSOR SYNCHRONIZATION）
従来の同期モデルにおいて維持されている基本的な前提条件の１つは、スレッドがカーネルから去る準備ができ、又はリソースがブロックされるまで、スレッドが、カーネルの占有権（exclusive rights）及びカーネルの使用権を維持すること（割込を除く）である。マルチプロセッサでは、各プロセッサは、カーネルコードを同時に実行することができるので、従来の同期モデルは、最早有効なモデルではなくなっている。複数のスレッドを用いるマルチプロセッサモデルの下では、各プロセッサが、カーネルコードのそのコピーを実行できるときには、全ての種類のデータを保護する必要がある。本発明の下では、１つの環境内に複数のカーネルがあり、各カーネルは、カーネルコードのそれら自体のコピーを実行する複数のプロセスによる動作の結果として、複数のスレッドを有するので、この種の保護は有効である。

プロセッサマネージャ（PROCESSOR MANAGER）
本発明の下では、プロセッサ、したがってＣＰＵは、他のリソースと同様に、管理されるリソースとなる。より具体的には、プロセッサマネージャは、ＣＰＵの数と、環境の下で動作するカーネル、又はカーネルスレッドの使用を管理するカーネル固有のプロセスのコピーに対するＣＰＵの割当とを管理するプロセスである。特別なカーネルコードのコピーを実行して、特定のリソースを利用するカーネルスレッドを使用するための各要求は、プロセッサマネージャによって管理される。プロセッサの数は、プロセッサマネージャによって、分類されて（catalogued）、現在の環境内で実行中の各スレッドに割り当てられなければならない。

一具体例では、複数のプロセスが通信するためのプロセス間通信テーブル、特に最新のカーネル内に存在するプロセス間通信テーブルに対するアクセスを提供する。プロセス間通信テーブルのデータ構造は、割込ハンドラ（interrupt handler）によってはアクセスされず、データ構造にアクセスするプロセスをブロックする可能性がある如何なる動作もサポートしていない。したがって、ユニプロセッサシステム（uniprocessor system）では、カーネルは、テーブルをロックすることなく、テーブルを操作することができる。しかしながら、マルチプロセッサシステム（multiprocessor system）の下では、こういうことは、行うことができない。したがって、本発明の下では、このようなテーブルは、常駐するカーネルコードの複数のコピーを実行する複数のプロセスが協調し（cooperation）、及び他のカーネルに接続された（attached）複数のリソースを使用することが必要な複数のカーネルが協調するように、拡張しなければならない。本発明では、２つのプロセスが、プロセス間で同時に通信するために、このようなテーブルに一旦アクセスすると、このようなテーブルをロックしなければならず、プロセッサマネージャがこのようなテーブルの管理を実行できるように、現在の抽象化（abstract）を変更することを提案する。２つ以上のプロセスが同時にＩＰＣテーブルにアクセスすることを試みたとき、プロセッサマネージャは、１つ以上のプロセスがそれらの通信リンクを終了するまで、且つ他のプロセスがＩＰＣテーブルにアクセスすることが許可されるようになる前に、ＩＰＣテーブルをロックしなければならない。ロック機構（locking mechanism）は、ＩＰＣ通信の基本であり、本発明の下では、ロック機構は、３つ以上のプロセスが同時に通信できるようにするために、マルチプロセッサシステムのＩＰＣ通信に対応するように拡張することができる。

プロセス間通信テーブル（Inter-process Communication Table）
カーネル間通信テーブル（INTER-KERNEL COMMUNICATION TABLE）
従来のカーネルシステムの下では、カーネルは、単にロックフラグを調べ、カーネル間通信テーブルをロックするために、ロックフラグをロック位置に設定し、あるいは、カーネル間通信テーブルをアンロックするために、ロックフラグをリセットするようになっている。本発明の下では、プロセス間通信（ＩＰＣ）及びカーネル間通信（ＩＫＴ）は、それらに応じて管理されるシステム内のもう１つのリソースになる。これらのテーブルの複雑性（complexity）によって、システム環境の洗練度（sophistication）のレベルが決まる。本発明の下では、マルチプロセッサシステムの場合に、異なるプロセッサ上で動作するが、１つのプロセッサマネージャによって管理される２つのスレッドは、同じリソースに対する単一のロックフラグを同時に調べることができる。両方のスレッドは、ロックフラグが解除されたことが分かると、同時に特定のリソースにアクセスすることを試みる。したがって、本発明では、１つのプロセスだけがロックフラグの検査を実行し、この場合、このような検査は、リソースがプロセッサである場合には、プロセッサマネージャによって行われ、リソースがプロセッサ以外のものである場合には、リソースマネージャによって行われる。このようなマネージャの分割によって、同時のアクセスが予測できない結果となることを、ある程度防止することができる。

スレッドマネージャ（THREAD MANAGER）
本発明では、スレッドマネージャは、現在のローカルカーネル（local kernel）の下で動作するプロセスとして定義され、現在のローカルカーネルの下で動作する軽量プロセス（lightweight process：ＬＷＰ）及び他のプロセスに割り当てられた全てのスレッドの使用を追跡する。スレッドマネージャは、この情報を、複数のカーネル環境（Multiple Kernel Environment：ＭＫＥ）の同期を支援するように動作する他の管理システムに報告する。ＭＫＥが上述した５つの構成のうちの１つに組織化された場合、スレッドマネージャの報告は、この特定の環境の必要条件を満たすように変更することができる。スレッドマネージャにとって、重要なことは、例えば、特定のシステムの下で、所定のリソースをより正確に追跡するために、割り当てられたスレッドの数を報告することである。リソースの報告は、リソースマネージャの役割であり、したがって、リソースマネージャは、この種類の情報を提供するスレッドマネージャに依存する。

リソースマネージャ（RESOURCE MANAGER）
本発明では、リソースマネージャは、環境内に存在すると考えられるリソースのマネージャとして定義される。例えば、リソースは、あらゆるオペレーティングシステム環境に不可欠なコンポーネントであると考えられ、したがって、複数のカーネルが常駐する又は常駐できるシステムの下では、このステートメント（statement）は、重要な意味を持つ。リソースマネージャは、ローカルカーネルレベルに常駐するリソースを管理し、あるタスクが特定のリソースを要求する毎に、これらの要求は、リソースマネージャを介して行われ、特定のカーネル上では利用不可能なリソースに対する要求が行われた場合、リソースマネージャは、リソースを必要とするタスクと、特定のリソースを有するカーネルとの間に関係を築くために、関係マネージャに連絡する。

リソース割当マネージャ（RESOURCE ALLOCATION MANAGER）
本発明では、リソース割当マネージャは、特定のリソースを用いて１つのカーネル上で開始するが、他のカーネルに接続（attached）される可能性があるリソースを必要とする開始タスクを有するプロセス間に割り当てられた全てのリソースの記録を行う。このような状況では、リソースマネージャは、特定のリソースを見つけ、あるいは環境内の利用可能な全てのリソースの目録を作る（inventory）ためには、リソース割当マネージャと連絡する必要がある。このような場合、カーネル間の全てのリソース割当を管理するリソース割当マネージャは、必要な情報をリソースマネージャに供給する。

あるアーキテクチャの下では、リソース割当マネージャ及びリソースマネージャは、コマンドカーネルシステム又は環境内のオペレーティングシステム以外の、ＯＳ又はカーネルシステム内に存在することができる。本発明の実施の形態を説明するために、リソース割当マネージャ及びリソースマネージャの両方は、コマンドオペレーティング及びカーネルシステム（Command Operating and Kernel System）の一部として存在しているものとする。

更なる具体例
図１４〜図２３は、本発明の実施の形態のより詳細な具体例を示している。本発明の一実施の形態では、ＫＯＳは、中央ではなく、個々のオペレーティングシステム内で実行される。プロセスは、情報を、例えば共有メモリを用いて交換して、何時リソースが利用可能か、又は何時リソースが利用可能になるかを他のプロセスに通知する。一具体例として、図１４は、リソースＲ１に関する情報を、共有メモリ１０１５を用いて交換する２つのプロセス１００１、１０１０を示している。共有メモリ１０１５は、プロセス１０１０が待っているリソースＲ１が、今利用可能になったことを示す情報を含んでいる。このとき、プロセス１０１０は、リソースＲ１を、例えばリソースＲ１に対するコールを生成することによって要求することができる。

なお、図１４では、単一のリソースに関する情報を含む共有メモリを示したが、他の実施の形態では、共有メモリは、多くのリソースに関する情報を含んでいる。また、共有メモリは、図１４に示す情報とは異なる情報、又はこれに加えて更なる情報を含むことができる。

他の実施の形態においては、各ＫＯＳは、他のＫＯＳ及びそれらがサポートしているリソースを示すテーブルを含んでいる。また、このテーブルは、リソースがどのように呼び出されるか（例えば、オペレーティングシステムに対するエントリポイント又はシステムコールによって）と、現在、特定のオペレーティングシステムを実行しているプロセッサの負荷とを示す。例えば、図１５Ａ〜図１５Ｃは、３つのプロセッサが存在し、各プロセッサが、ＫＯＳを実行するとともに、異なるリソースをサポートする環境において、各ＫＯＳ内のテーブルの具体例を示している。図１５Ａは、オペレーティングシステムＯＳ１に記憶されているテーブルを示している。図１５Ａの行１１０１は、オペレーティングシステムＯＳ２がエントリポイントＰ２を有し、リソースＲ２、Ｒ３をサポートし、システム（プロセッサ）の負荷が１０％であることを示している。行１１０３は、オペレーティングシステムＯＳ３がエントリポイントＰ３を有し、リソースＲ３をサポートし、システムの負荷が４０％であることを示している。

オペレーティングシステムＯＳ２に記憶されている図１５Ｂのテーブル及びオペレーティングシステムＯＳ３に記憶されている図１５Ｃのテーブルは、同じように説明されるので、ここでは説明しない。動作において、オペレーティングシステムは、互いに情報を、周期的に、例えば特定の時間毎に、あるいは所定の閾値を超えてそのリソースパラメータが変化したときに交換する。

図１６は、リソース情報を異なるフォーマットで格納し、リソースをオペレーティングシステムにマッピングするテーブル１２００を示している。例えば、図１６のテーブル１２００の行１２０１は、現在、リソースＲ１がオペレーティングシステムＯＳ１を介してアクセス可能であることを示しており、行１２０２は、リソースＲ２がオペレーティングシステムＯＳ２、ＯＳ１を介してアクセス可能であることを示しており、行１２０３は、リソースＲ３がオペレーティングシステムＯＳ２、ＯＳ３を介してアクセス可能であることを示している。

図１５Ａ〜図１５Ｃ及び図１６のテーブルは、単に例示的に示しているだけである。当業者は、本発明の実施の形態に基づき、リソーステーブルに含まれる多くの異なるフォーマット及び種類の情報を想到することができる。

図１７は、本発明の一実施の形態に基づき、複数のＫＯＳがリソース情報を交換するシステム１２５０を示している。システム１２５０は、関係マネージャ１２５１Ａ及びリソースマネージャ１２５１Ｂを有するＫＯＳ１２５１と、関係マネージャ１２５５Ａ及びリソースマネージャ１２５５Ｂを有するＫＯＳ１２５５と、関係マネージャ１２６０Ａ及びリソースマネージャ１２６０Ｂを有するＫＯＳ１２６０とを備える。上述したように、ＫＯＳがリソースを必要としたとき、ＫＯＳは、そのローカルのカーネルレベルを、リソースマネージャを用いて調べる。リソースを見つけることができない又はリソースが利用不可能な場合、ＫＯＳは、その関係マネージャを呼び出して、他のＫＯＳを介してリソースにアクセスする。

図１８〜図２３は、本発明に基づく中央のＫＯＳ（central KOS）の実施の形態を示している。図１８は、それぞれが１つ以上のリソースにアクセスするように構成された複数のオペレーティングシステムＯＳ１（１３１０）、ＯＳ２（１３１１）、ＯＳ３（１３１２）、ＯＳ４（１３１３）を実行するコンピュータシステム１３００を示している。オペレーティングシステムＯＳ１（１３１０）、ＯＳ２（１３１１）の両方は、プリンタ１３２０にアクセスするように構成されている。オペレーティングシステムＯＳ３（１３１２）は、ディスク１３２１にアクセスするように構成されており、オペレーティングシステムＯＳ４（１３１３）は、ビデオディスプレイ１３２２にアクセスするように構成されている。一実施の形態においては、オペレーティングシステムＯＳ４（１３１３）は、特に、ビデオディスプレイ１３２２とインタフェースするように適応化されている。すなわち、例えば、オペレーティングシステムＯＳ４（１３１３）は、ビデオディスプレイドライバを備え、オペレーティングシステムＯＳ１（１３１０）、ＯＳ２（１３１１）、ＯＳ３（１３１２）は、ビデオディスプレイドライバを備えていない、あるいは、ビデオディスプレイ１３２２に対するオペレーティングシステムＯＳ４（１３１３）のインタフェースは、より多くの特徴、例えばメモリ使用量が少ない、より速い等、又はこれらを組み合わせた特徴をサポートしている。システム１３００上の一部のオペレーティングシステムだけが所定のリソースにアクセスするように構成され、他のオペレーティングシステムがこのように構成されていない、あるいは、幾つかのオペレーティングシステムが、他のオペレーティングシステムに比して、特定のリソースにアクセスするのに適しているという多くの理由は、当業者にとって明らかである。

動作において、プロセスは、リソースを使うことを要求し、カーネル動作スケジューラ（kernel operational scheduler：ＫＯＳ）１３０５に導入される。ＫＯＳ１３０５は、まず、オペレーティングシステムＯＳ１（１３１０）〜ＯＳ４（１３１３）のうちのどれが、要求されたリソースをプロセスに供給するに最適であるかを決定し、次に、選択したオペレーティングシステムにプロセスを割り当てる。複数のオペレーティングシステムが要求されたリソースを供給することができるときは、ＫＯＳ１３０５は、後述する選択基準を用いる。一具体例として、プロセスは、プリンタ１３２０にアクセスするために、プリント機能を呼び出す。オペレーティングシステムＯＳ１（１３１０）、ＯＳ２（１３１１）の両方がプリンタ１３２０にアクセスすることができるが、オペレーティングシステムＯＳ１（１３１０）の方がビジーでないので、オペレーティングシステムＯＳ１（１３１０）が選択される。

図１９は、ＫＯＳ１３０５を更に詳細に示している。図１９に示すように、一実施の形態では、ＫＯＳ１３０５は、コマンドカーネル１４００と、関係マネージャ１４１０とを備える。

図２０は、本発明の一実施の形態に基づき、図１９の関係マネージャ１４１０に記憶されているプロセステーブル（process table）１４５０を示す。プロセステーブル１４５０は、プロセスと、プロセスに割り当てられるリソースと、それらの優先度とに関する情報を格納している。例えば、テーブル１４５０の行１４５１は、プロセスＩＤ１５７２を有するプロセスは、現在、リソースＲ１が割り当てられているとともに、１位の優先度を有することを示している。

なお、プロセステーブル１４５０には、他の情報、例えば、幾つかの他の種類の情報を上げると、プロセスがリソースを待っているか、プロセスがどれくらい長くリソースを待っているかを示す情報を格納することができることは、明らかである。

図２１は、本発明の一実施の形態に基づいて、プロセスを処理するカーネルオペレーティングシステムをスケジューリングする方法１５００のフローチャートである。開始ステップ１５０１に続くステップ１５０３において、処理は、コンピュータシステム上で実行されているオペレーティングシステム（ＯＳ）のうちのどれがリソースを供給することができるかを判定する。次に、ステップ１５０５において、処理は、２つ以上のＯＳがリソースを供給することができるかを判定する。ＯＳのうちの１つだけがリソースを供給することができる場合、処理は、ステップ１５１５にスキップし、該当する場合、処理は、ステップ１５１０に進む。

ステップ１５１０において、処理は、図２２に関連して後述するように、１つ以上の選択基準を用いて、複数のＯＳのうちの１つを選択し、ステップ１５１５に進む。ステップ１５１５において、処理は、リソースをプロセスに割り当て、ステップ１５２０において、終了する。

図２２は、要求された全てのリソースを供給することができる複数のカーネルオペレーティングシステムの中から１つのカーネルオペレーティングシステムを選択する、図２１に示すステップ１５１０の詳細を示している。最初のステップ１５５０において、処理は、負荷が最小のオペレーティングシステムを選択する。ステップ１５５５において、処理は、１つのＯＳがこの基準を満たすかを判定する。該当する場合、処理は、ステップ１５７５にスキップする。該当しない場合、処理は、ステップ１５６０に進み、最少の負荷を有するＯＳのみを検討から外す。

ステップ１５６０において、処理は、残りのＯＳから、実行待ちプロセス又はブロックプロセスが最も少ないＯＳのみを選択して、残りを検討から外す。ステップ１５６５において、処理は、実行待ちプロセス又はブロックプロセスが最も少ないＯＳが１つだけかを判定する。実行待ちプロセス又はブロックプロセスが最も少ないＯＳが１つだけの場合、処理は、ステップ１５７５にスキップする。該当しない場合、処理は、ステップ１５７０に進み、ここにおいて、残りのＯＳから、回転、すなわち他のラウンドロビン方式によって１つのＯＳを選択する。次に、ステップ１５７５において、処理は、選択されたＯＳを介して、要求されたリソースをプロセスに割り当てる。この処理は、ステップ１５８０において終了する。ここで、「選択基準」は、ＯＳの状態（実行待ちプロセス又はブロックプロセスの数、及びＯＳを実行しているプロセッサの負荷）を含んでいると言える。

なお、ステップ１５１０は、単に例示的に示しているだけである。当業者は、多くの変形例を想到することができる。例えば、ステップ１５１０のステップは、異なる順序に並べ替えてもよく、幾つかのステップを追加してもよく、幾つかのステップを削除してもよく、あるいは、全く異なるステップの組を実行してもよい。異なるステップの１つとして、２つのＯＳの両方がリソースを供給することができる場合、より高速のマイクロプロセッサ上で実行されているＯＳを選択する。

図２３は、本発明の一実施の形態に基づくシステム１６００のコンポーネントと、プロセスがコンピュータシステム上のリソースを要求したときのトランザクションのシーケンスとを示している。システム１６００は、プロセス１６１０Ａを実行して、リソース１６１０Ｂに対するアクセスを供給するオペレーティングシステム１６１０と、プロセス１６６０Ａを実行して、リソース１６６０Ｂ〜１６６０Ｄに対するアクセスを供給するオペレーティングシステム１６６０と、ＫＯＳ１６５０とを備える。

図２３に示すように、プロセス１６１０Ａは、リソース１６６０Ｂに対する、例えばリソースマネージャを介した要求１７０６を生成する。破線１７０６で示すように、リソース１６６０Ｂは、ローカルでは入手できないので、リソース１６６０Ｂに対する要求１７２０がＫＯＳ１６５０に送られる。ＫＯＳ１６５０は、ＯＳ１６６０がリソースを供給することができると判定し、リソース１６６０Ｂに対する要求１７３０をＯＳ１６６０に送り、ＯＳ１６６０は、リソース１６６０Ｂを供給する。

リソースを供給する処理は、要求された特定のリソースによって異なる。リソースがＣＰＵである場合、割当は、プロセスの識別子を、ＯＳ１６６０内の実行待ちキュー（run queue）に設定することを含むことができる。リソースがディスクである場合、割当は、プロセスをディスクにディスパッチするキューに、プロセスを置くことを含むことができる。

本発明では、プロセスを、１つのＯＳから他のＯＳに渡す（handed-off）ことができる。一具体例として、プロセスが、１つのＯＳを介してリソースにアクセスしているときに、そのＯＳを実行しているプロセッサに他のタスクが割り当てられた場合には、プロセスは遅くなる。換言すれば、ＯＳもリソースである。本発明に基づくＫＯＳは、プロセスを、より効率的に実行できる他のＣＰＵに再び割り当てることができる。

本発明の実施の形態では、リソースを効率的に共有することができ、リソースを供給するオペレーティングシステム間で負荷をバランスさせることができる。これにより、ボトルネック、プロセス飢餓及びマルチプロセッサシステムに悪影響を与える他の徴候を低減することができる。更に、リソース及び特定のタスクを実行するように特化されたオペレーティングシステムを、プロセスに容易に割り当てることができ、これにより、プロセスを効率的に実行することができる。

なお、ここに説明した本発明に基づくＫＯＳ、その各コンポーネント、各アルゴリズムは、ＫＯＳの機能を実現するためにコンピュータにより実行可能な命令として、コンピュータにより読取可能な媒体に、記録することができる。これらの命令は、１つ以上のソフトウェアコンポーネントとしてコンピュータにより読取可能な媒体に記録してもよく、１つ以上のハードウェアコンポーネントであってもよく、これらの組合せであってもよく、コンピュータによって使用され、アルゴリズムのステップを実行する如何なる要素であってもよい。

本発明の原理及び動作の理解を容易にするために、本発明の特定の実施の形態を詳細事項を用いて説明してきたが、ここで参照した特定の実施の形態及びその詳細事項は、本発明の請求の範囲を限定するものではない。本発明の趣旨及び範囲から逸脱することなく、上に例示した実施の形態を変更できることは、当業者にとって明らかである。

Claims (11)

1. 複数のプロセッサを含む複数のリソースと、
   コンピュータシステム上で実行されるプロセスに対するリソースの割当をそれぞれのリソースの間で調整するカーネルスケジューラをそれぞれ含む複数のカーネルオペレーティングシステムを記憶したメモリとを備え、
   上記複数のプロセッサは、複数のカーネルオペレーティングシステムのうちの異なる１つをそれぞれ実行し、
   上記複数のカーネルオペレーティングシステムのそれぞれは、他の複数プロセッサの負荷、リソースの利用可能性、リソースが利用可能になるまでの見積時間を含む他の複数のカーネルオペレーティングシステムのリソース情報を交換することを特徴とするコンピュータシステム。
2. 上記複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の２つ以上を含むことを特徴とする請求項１記載のコンピュータシステム。
3. 上記複数のカーネルスケジューラは、リソース関連情報を、通信プロトコルを用いて共有することを特徴とする請求項１記載のコンピュータシステム。
4. 上記通信プロトコルは、共有メモリにアクセスすることを含むことを特徴とする請求項３記載のコンピュータシステム。
5. 上記通信プロトコルは、プロセス間通信又はプロトコルスタックを含むことを特徴とする請求項３記載のコンピュータシステム。
6. 上記通信プロトコルは、伝送制御プロトコル／インターネットプロトコルを含むことを特徴とする請求項３記載のコンピュータシステム。
7. 上記通信プロトコルは、セマフォ、パイプ、信号、メッセージキュー、データに対するポインタ及びファイル記述子にアクセスすることを含むことを特徴とする請求項３記載のコンピュータシステム。
8. 上記プロセスは、互いに通信する少なくとも３つのプロセスからなることを特徴とする請求項３記載のコンピュータシステム。
9. 上記複数のカーネルスケジューラのそれぞれは、他の関係マネージャによって上記リソースを要求する関係マネージャを備えることを特徴とする請求項１記載のコンピュータシステム。
10. 上記複数の関係マネージャのそれぞれは、上記複数のリソースのうちの１つ以上に関するリソース情報を検出するリソースマネージャを備えることを特徴とする請求項９記載のコンピュータシステム。
11. 上記リソース情報は、リソースが利用可能になるまでの見積時間を含むことを特徴とする請求項１０記載のコンピュータシステム。

Images