JP5891284B2 - コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 - Google Patents
コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 Download PDFInfo
- Publication number
- JP5891284B2 JP5891284B2 JP2014204814A JP2014204814A JP5891284B2 JP 5891284 B2 JP5891284 B2 JP 5891284B2 JP 2014204814 A JP2014204814 A JP 2014204814A JP 2014204814 A JP2014204814 A JP 2014204814A JP 5891284 B2 JP5891284 B2 JP 5891284B2
- Authority
- JP
- Japan
- Prior art keywords
- kernel
- resource
- operating system
- resources
- scheduler
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Description
本発明は、コンピュータシステムに関する。より詳しくは、本発明は、複数のオペレーティングシステムを実行するコンピュータシステム上のプロセスにリソースを割り当てることに関する。
コンピュータによって使用されるリソースは、コンピューティング環境によって変化し、また、それらに分散されているが、リソースは、ジョブを実行できるようにする前に、必要とされる。複数のプロセスを同時に実行するとき、それが普通であるが、ボトルネックは、リソースにおいて生じる。これらのボトルネックは、I/Oバスコントローラ、スワップシーケンス中のメモリコントローラにおいて生じることがあり、あるいは、メモリダンプが開始されたときに、それがメモリ負荷を要求するために、プログラムが中断される(preempted)ときにも発生する。
ボトルネックの発生、したがってプロセス飢餓(process starvation)は、複数のオペレーティングシステムを実行するコンピュータシステムでさえも増えている。これらのオペレーティングシステム上で実行されているプロセスが増加すると、複数のプロセスが同じリソースを同時に要求する、又はリソースの解放を互いに待っているプロセスが飢餓する確率が高くなる。
本発明の第1の側面におけるコンピュータシステムは、複数のリソースと、複数のオペレーティングシステムを記憶したメモリとを備える。各オペレーティングシステムは、コンピュータシステム上で実行されるプロセスに対するリソースの割当を調整するカーネルスケジューラを含んでいる。一実施の形態において、また、コンピュータシステムは、複数のオペレーティングシステムのうちの異なる1つをそれぞれ実行する複数の中央演算処理装置を備える。複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の2つ以上を含んでいる。
好ましくは、複数のカーネルスケジューラは、リソース関連情報を、通信プロトコルを用いて共有する。一実施の形態において、通信プロトコルは、共有メモリにアクセスする。あるいは、通信プロトコルは、プロセス間通信、プロトコルスタック又は伝送制御プロトコル/インターネットプロトコル(Transmission Control Protocol/Internet Protocol:TCP/IP)を含んでいる。あるいは、通信プロトコルは、セマフォのアクセス(accessing semaphores)、パイプ(pipes)、信号(signals)、メッセージキュー、データに対するポインタ及びファイル記述子(file descriptors)を含んでいる。一実施の形態において、プロセスは、互いに通信する少なくとも3つのプロセスからなる。
一実施の形態において、複数のカーネルスケジューラのそれぞれは、リソースの割当を調整する関係マネージャ(relationship manager)を備える。複数の関係マネージャのそれぞれは、複数のリソースのうちの1つ以上に関するリソース情報を判定するリソースマネージャ(Resource Manager)を備える。リソース情報は、リソースが利用可能になるまでの見積時間(estimated time)である。
本発明の第2の側面におけるコンピュータシステムは、1つのカーネルスケジューラと、複数のリソースにアクセスする複数のオペレーティングシステムカーネル(operating system kernel)とを記憶したメモリを備える。カーネルスケジューラは、複数のリソースのうちの1つのリソースを要求するプロセスを、複数のオペレーティングシステムカーネルのうちの対応する1つに割り当てる。また、コンピュータシステムは、それぞれが複数のオペレーティングシステムカーネルのうちの対応する1つを実行する複数のプロセッサを備える。
一実施の形態において、カーネルスケジューラは、複数のオペレーティングシステムカーネル上のプロセスを、複数のプロセッサの負荷に基づいてスケジューリングする。
一実施の形態において、また、コンピュータシステムは、リソースの要求を、複数のオペレーティングシステムカーネルのうちの1つ以上に照合する(matches)プロセステーブルを備える。他の実施の形態においては、また、コンピュータシステムは、複数のオペレーティングシステムカーネルのうちのペア間の通信チャンネルを備える。複数のオペレーティングシステムカーネルは、プロセッサの負荷と、リソースの利用可能性と、リソースが利用可能になるまでの見積時間とに関する情報を交換する。
本発明の第3の側面におけるカーネルスケジューリングシステムは、複数のプロセッサと、割当モジュール(assignment module)とを備える。複数のプロセッサのそれぞれは、1つ以上のリソースにアクセスするオペレーティングシステムカーネルを実行する。割当モジュールは、リソースにアクセスできる複数のオペレーティングシステムカーネルのうちの1つに、リソースを要求するプロセスを照合し、プロセスをディスパッチするようにプログラムされている。好ましくは、複数のプロセッサのそれぞれは、対応するプロセッサスケジューラ(processor scheduler)によって制御される。
本発明の第4の側面におけるリソースをオペレーティングシステムカーネルに割り当てるリソース割当方法は、複数のオペレーティングシステムカーネルの中から1つのオペレーティングシステムカーネルを、そのリソースにアクセスする能力に基づいて選択するステップと、選択されたオペレーティングシステムカーネルにプロセスを割り当てるステップとを有する。複数のオペレーティングシステムカーネルの全ては、単一メモリ(single memory)内で実行される。
本発明の第5の側面におけるシングルコンピュータシステムのメモリ上の第1のオペレーティングシステムと第2のオペレーティングシステム間でプロセス実行(process execution)を共有するプロセス実行共有方法は、メモリ内でプロセスを、第1のオペレーティングシステムの制御の下に実行するステップと、プロセスの制御を、第2のオペレーティングシステムにメモリ内で移して、メモリ内でプロセスを、第2のオペレーティングシステムの制御の下に実行するステップとを有する。このように、プロセスは、第2のオペレーティングシステムの制御の下に、メモリ内で実行される。第1のオペレーティングシステムと第2のオペレーティングシステムの制御の下でのプロセスの実行の両方では、単一のリソースにアクセスする。一実施の形態において、プロセス実行共有方法は、第1のオペレーティングシステムと第2のオペレーティングシステム間で、共有メモリ、プロセス間通信及びセマフォのうちの1つを用いて、プロセス情報を交換するステップを更に有する。
本発明に基づく、直列に動作する(run in tandem)複数のオペレーティングシステムは、リソースを必要とするプロセスに割り当てるリソースを共有し、これによって、ボトルネック及びリソース競合の他の徴候を低減する。一実施の形態において、リソースは、リソースを必要とするプロセスにリソースを割り当てるオペレーティングシステムを調整する中央のカーネル動作スケジューラ(central kernel operating scheduler)を用いて、集中的に割り当てられる。他の実施の形態において、リソースは、ピアツーピア方式で、リソースの配分をそれら自体で調整するオペレーティングシステムによって供給される。この実施の形態では、オペレーティングシステムは、確立されたプロトコル(well-established protocols)を用いて、通信する。
本発明においては、コンピュータシステム上で実行される幾つかのオペレーティングシステムは、特定のタスクを実行するように特化されている。特定のリソース割当に対する要求を実行するように特化されたオペレーティングシステムでは、他の要求が溜まっている(backlogged)リソースに対する要求が受信されると直ちに、オーバフローした要求は、中央のオペレーティングシステム(centralized Operating System)ではなく、リソースオペレーティングシステムによって、単にキューに入れられる。
プロセス管理(Process management)
カーネルの主な仕事は、アプリケーションの実行を許可し、例えばハードウェアを抽象化する機能によって、アプリケーションを支援することである。プロセスは、アプリケーションがどのメモリ部分にアクセスできるかを定義する(この導入部では、プロセス、アプリケーション及びプログラムは、同義語として用いられている)。カーネルのプロセス管理は、メモリ保護が組み込まれたハードウェアを考慮しなければならない。
カーネルの主な仕事は、アプリケーションの実行を許可し、例えばハードウェアを抽象化する機能によって、アプリケーションを支援することである。プロセスは、アプリケーションがどのメモリ部分にアクセスできるかを定義する(この導入部では、プロセス、アプリケーション及びプログラムは、同義語として用いられている)。カーネルのプロセス管理は、メモリ保護が組み込まれたハードウェアを考慮しなければならない。
アプリケーションを動作させるために、カーネルは、通常、アプリケーション用のアドレス空間を準備して、(多くの場合は、デマンドページングによって、)アプリケーションのコードを含むファイルをメモリにロードし、プログラムのスタックを準備して、プログラム内の所定の位置に分岐するように、アプリケーションの実行を開始する。
マルチタスクのカーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。通常、コンピュータシステムが同時に動作させることができるプロセスの数は、実装されているCPUの数に等しい(なお、プロセッサが同時マルチスレッディング(simultaneous multithreading)をサポートしている場合は、この限りではない)。
プリエンプティブマルチタスクシステム(preemptive multitasking system)では、カーネルは、タイムスライスを全てのプログラムに与え、これらのプロセスが同時に実行されているかのようにユーザに見せるほど速く、プロセスから他のプロセスに切り換える。カーネルは、スケジューリングアルゴリズムを用いて、次にどのプロセスを動作させるか、及びどのくらいの時間を与えるかを決定する。選択されたスケジューリングアルゴリズムは、あるプロセスに他のプロセスよりも高い優先度を与えることができる。また、カーネルは、通常、これらのプロセスに、通信する方法を提供する。この方法は、プロセス間通信(inter-process communication:IPC)と呼ばれ、主な手法は、共有メモリ(shared memory)、メッセージパッシング(message passing)及びリモートプロシージャコール(remote procedure calls)である。
他のコンピュータシステム(特に、より小型で、より性能が低いコンピュータ)は、協調的マルチタスク(co-operative multitasking)を有し、協調的マルチタスクでは、各プロセスは、他のプロセスに切り換えてもよいことをカーネルに告げる特別な要求を出すまでは、中断することなく、動作することができる。このような要求は、「明け渡し(yielding)」と呼ばれ、通常、プロセス間通信の要求に応じて、あるいは発生するイベントを待つために、起こる。Windows(登録商標)及びMacOS(登録商標)の旧バージョンは、何れも、協調的マルチタスクを用いていたが、これらは、対象のコンピュータの性能が高まったので、プリエンプティブ方式に切り換えられた。
また、オペレーティングシステムは、マルチプロセス(対称型マルチプロセッサ(Symmetric Multiprocessor:SMP)又は非均質メモリアクセス(Non-Uniform Memory Access))をサポートしていることもある。この場合、異なるプログラム及びスレッドは、異なるプロセッサ上で動作することができる。このようなオペレーティングシステムのカーネルは、カーネルがそのコードの2つの異なる部分を同時に問題なく動作できることを意味するリエントラント(re-entrant)となるように設計しなければならない。これは、通常、2つのプロセッサが同時に同じデータを変更しようとしないことを保証する同期機構(例えばスピンロック(spinlock))を設けることを意味する。
メモリ管理(Memory Management)
オペレーティングシステムには、通常、カーネル、すなわちコンピュータの中核として動作する一群の中心的な制御プログラム(centralized control program)が組み込まれている。これらの制御プログラムの中には、次のプロセスに対してCPU時間を直列に予約する役割を果たすスケジューラプログラムが含まれている。本発明は、1CPU当たり1オペレーティングシステムであって、複数のCPU上で動作する複数のオペレーティングシステムを用いる。各オペレーティングシステムは、カーネル動作スケジューラ(Kernel Operational Scheduler:KOS)と呼ぶ独特なスケジューラプログラムを有する専用のカーネルを有する。全てのKOSは、初期化中に、それ自体を構成する能力を有し、コンピュータシステムに搭載されている各CPU用のオペレーティングシステムカーネル(operating system kernel)のバイナリコードのコピーをシステム生成(sysgen)する(システム生成とは、特定の、独自に定められたオペレーティングシステム、又は独立したソフトウェアコンポーネントを組み合わせることによって、他のプログラムを生成することを意味する)。各カーネルが、一旦、適切に準備されて、各CPUに連結されると、KOSスケジューラ(KOS schedulers)は、各カーネル間の通信を確立し、どのカーネルがどのリソースを制御するかを決定する。
オペレーティングシステムには、通常、カーネル、すなわちコンピュータの中核として動作する一群の中心的な制御プログラム(centralized control program)が組み込まれている。これらの制御プログラムの中には、次のプロセスに対してCPU時間を直列に予約する役割を果たすスケジューラプログラムが含まれている。本発明は、1CPU当たり1オペレーティングシステムであって、複数のCPU上で動作する複数のオペレーティングシステムを用いる。各オペレーティングシステムは、カーネル動作スケジューラ(Kernel Operational Scheduler:KOS)と呼ぶ独特なスケジューラプログラムを有する専用のカーネルを有する。全てのKOSは、初期化中に、それ自体を構成する能力を有し、コンピュータシステムに搭載されている各CPU用のオペレーティングシステムカーネル(operating system kernel)のバイナリコードのコピーをシステム生成(sysgen)する(システム生成とは、特定の、独自に定められたオペレーティングシステム、又は独立したソフトウェアコンポーネントを組み合わせることによって、他のプログラムを生成することを意味する)。各カーネルが、一旦、適切に準備されて、各CPUに連結されると、KOSスケジューラ(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)は、この2つを明確に区別し、自然に、マイクロカーネル設計に通じる(保護とセキュリティの分離を参照)。
モノリシックカーネルは、それらのコードの全てを、同一のアドレス空間(カーネル空間)で実行するが、マイクロカーネルは、それらのサービスの殆どを、ユーザ空間で動作させることによって、コードベース(codebase)の保守性及びモジュール性を向上させることを意図している。殆どのカーネルは、厳密には、これらの分類の1つに収まらず、これらの2つの設計の中間に位置する。これらは、ハイブリッドカーネル(hybrid kernel)と呼ばれる。より斬新な設計、例えばナノカーネル(nanokernel)及びエクソカーネル(exokernel)が利用可能であるが、製品のオペレーティングシステムとしては殆ど使用されていない。例えば、Xenハイパーバイザー(Xen hypervisor)は、エクソカーネルである。
モノリシックカーネル(Monolithic Kernel)
モノリシックカーネルのダイヤグラム
モノリシックカーネルでは、全てのOSサービスは、主要なカーネルスレッド(kernel thread)と一緒に動作し、したがって、同じメモリ領域に存在する。この方法は、豊かで強力なハードウェアアクセスを提供する。何人かの開発者、例えばUNIX(登録商標)開発者であるケン・トンプソン(Ken Thompson)は、他の解決法に比べて、モノリシックカーネルのオペレーティングシステムは、設計及び実装が容易であると主張している。モノリシックカーネルの主な短所は、オペレーティングシステムのコンポーネント間の依存性、例えばデバイスドライバにおけるバグがオペレーティングシステム全体をクラッシュさせる可能性があり、大きなカーネルは、保守が非常に難しいという事実がある。
モノリシックカーネルのダイヤグラム
モノリシックカーネルでは、全てのOSサービスは、主要なカーネルスレッド(kernel thread)と一緒に動作し、したがって、同じメモリ領域に存在する。この方法は、豊かで強力なハードウェアアクセスを提供する。何人かの開発者、例えばUNIX(登録商標)開発者であるケン・トンプソン(Ken Thompson)は、他の解決法に比べて、モノリシックカーネルのオペレーティングシステムは、設計及び実装が容易であると主張している。モノリシックカーネルの主な短所は、オペレーティングシステムのコンポーネント間の依存性、例えばデバイスドライバにおけるバグがオペレーティングシステム全体をクラッシュさせる可能性があり、大きなカーネルは、保守が非常に難しいという事実がある。
マイクロカーネル(Microkernel)
マイクロカーネル法(microkernel approach)では、カーネル自体は、以前のカーネルの機能、例えばデバイスドライバ、GUIサーバ等を承継した独立のプログラムをサーバが実行できるようにする基本機能だけを備える。
マイクロカーネル法(microkernel approach)では、カーネル自体は、以前のカーネルの機能、例えばデバイスドライバ、GUIサーバ等を承継した独立のプログラムをサーバが実行できるようにする基本機能だけを備える。
マイクロカーネル法は、必要最低限のOSサービス、例えばメモリ管理、マルチタスク及びプロセス間通信を実行する一連の基本命令(primitive)、すなわちシステムコール(system call)によって、ハードウェアの単純な抽象化(abstraction)を定義することを含んでいる。通常、カーネルが提供するサービスを含む他のサービス、例えばネットワークサービスは、サーバと呼ばれるユーザ空間のプログラムで実行される。マイクロカーネルは、モノリシックカーネルに比べて簡単に保守することができるが、システムコール及びコンテキストスイッチ(context switch)が多くなり、このようなシステムコール及びコンテキストスイッチは、典型的に、単純な関数コール(plain function call)に比べて、より大きなオーバヘッドを発生するので、処理速度が低下する可能性がある。
マイクロカーネルでは、オペレーティングシステムの残りの部分を、高級言語で書かれた普通のアプリケーションプログラムとして実装することができ、同じカーネルを、変更することなく、異なるオペレーティングシステム上で用いることができる。また、複数のオペレーティングシステム間を動的に切り換えて、複数のオペレーティングシステムを同時にアクティブにすることができる。
モノリシックカーネル対マイクロカーネル
コンピュータのカーネルが進化するにつれ、幾つかの問題が明らかになってきた。最も明白な問題の1つは、メモリ使用量(footprint)が増えるということである。これは、仮想メモリシステムを改良することによって、ある程度軽減されるが、全てのコンピュータアーキテクチャが仮想メモリをサポートしているわけではない。カーネルのメモリ使用量を少なくするためには、大規模な編集を行い、不必要なコードを注意深く除去する必要があり、これは、数百万ものコード行を有するカーネルの部分間の相互依存性が理解し難いので、非常に困難である。モノリシックカーネルが抱える問題のために、モノリシックカーネルは、1990年代初頭には、時代遅れであるとみなされていた。この結果、マイクロカーネルではなく、モノリシックカーネルを採用したLinux(商標)の設計は、リーヌス・トーヴァルズ(Linus Torvalds)と、アンドリュー・タネンバウム(Andrew Tanenbaum)との間の有名な議論の主題となった。タネンバウム/トーヴァルズ議論では、何れの意見にも長所があった。初期のUNIXの開発者ケン・トンプソン(Ken Thompson)を含む何名かは、マイクロカーネル設計は、美的に魅力があるが、モノリシックカーネルの方がより簡単に実装できると主張した。しかしながら、モノリシックカーネルのオペレーティングシステムにおけるバグは、通常、オペレーティングシステム全体をクラッシュさせ、一方、サーバがメインスレッドとは別に動作するマイクロカーネルでは、このようなことは起こらない。モノリシックカーネルの支持者は、間違ったコードがカーネルに入ることはなく、また、マイクロカーネルは、コードが正しいことによる利点を殆ど提供しないと結論づけている。マイクロカーネルは、多くの場合、クラッシュに対する耐性(crash tolerance)が重要な埋め込み型のロボット用コンピュータ又は医療用コンピュータにおいて用いられており、殆どのOSのコンポーネントは、それ自体に専用の保護されたメモリ空間に存在する。これは、モノリシックカーネルでは不可能であり、最新のモジュールローディングのモノリシックカーネルでも不可能である。
コンピュータのカーネルが進化するにつれ、幾つかの問題が明らかになってきた。最も明白な問題の1つは、メモリ使用量(footprint)が増えるということである。これは、仮想メモリシステムを改良することによって、ある程度軽減されるが、全てのコンピュータアーキテクチャが仮想メモリをサポートしているわけではない。カーネルのメモリ使用量を少なくするためには、大規模な編集を行い、不必要なコードを注意深く除去する必要があり、これは、数百万ものコード行を有するカーネルの部分間の相互依存性が理解し難いので、非常に困難である。モノリシックカーネルが抱える問題のために、モノリシックカーネルは、1990年代初頭には、時代遅れであるとみなされていた。この結果、マイクロカーネルではなく、モノリシックカーネルを採用したLinux(商標)の設計は、リーヌス・トーヴァルズ(Linus Torvalds)と、アンドリュー・タネンバウム(Andrew Tanenbaum)との間の有名な議論の主題となった。タネンバウム/トーヴァルズ議論では、何れの意見にも長所があった。初期のUNIXの開発者ケン・トンプソン(Ken Thompson)を含む何名かは、マイクロカーネル設計は、美的に魅力があるが、モノリシックカーネルの方がより簡単に実装できると主張した。しかしながら、モノリシックカーネルのオペレーティングシステムにおけるバグは、通常、オペレーティングシステム全体をクラッシュさせ、一方、サーバがメインスレッドとは別に動作するマイクロカーネルでは、このようなことは起こらない。モノリシックカーネルの支持者は、間違ったコードがカーネルに入ることはなく、また、マイクロカーネルは、コードが正しいことによる利点を殆ど提供しないと結論づけている。マイクロカーネルは、多くの場合、クラッシュに対する耐性(crash tolerance)が重要な埋め込み型のロボット用コンピュータ又は医療用コンピュータにおいて用いられており、殆どのOSのコンポーネントは、それ自体に専用の保護されたメモリ空間に存在する。これは、モノリシックカーネルでは不可能であり、最新のモジュールローディングのモノリシックカーネルでも不可能である。
性能(Performance)
モノリシックカーネルは、システム性能を高めるために、そのコードの全てを同じアドレス空間(カーネル空間)に有するように設計されている。何人かの開発者、例えばUNIXの開発者のケン・トンプソンは、モノリシックカーネルのオペレーティングシステムは、プログラムを上手く書けば、非常に効率が良いと主張している。マイクロカーネル設計における、通常メッセージパッシング(message passing)に基づくプロセス間通信(IPC)方式は低速であり、モノリシックモデルは、このIPCではなく、共有カーネルメモリを用いることによって、より効率が良い傾向にある。
モノリシックカーネルは、システム性能を高めるために、そのコードの全てを同じアドレス空間(カーネル空間)に有するように設計されている。何人かの開発者、例えばUNIXの開発者のケン・トンプソンは、モノリシックカーネルのオペレーティングシステムは、プログラムを上手く書けば、非常に効率が良いと主張している。マイクロカーネル設計における、通常メッセージパッシング(message passing)に基づくプロセス間通信(IPC)方式は低速であり、モノリシックモデルは、このIPCではなく、共有カーネルメモリを用いることによって、より効率が良い傾向にある。
1980年代及び1990年代初頭に構成されたマイクロカーネルの性能は、劣っていた。特定のマイクロカーネルの幾つかの性能を実験に基づいて測定した研究でも、このような効率が悪い理由は解析されなかった。これらの性能に関する説明は、カーネルモードからユーザモードに切り換える周波数を高め(なお、保護のこのような多段階設計は、マイクロカーネルに固有なものではない)、プロセス間通信の周波数を高め(なお、IPCは、以前に信じられていた速度よりも一桁速く実行することができる)、及びコンテキストスイッチの周波数を高めることによる一般的で、証明されていない考えを有する伝説(folklore)とされた。実際、これらの性能が低い理由は、1995年に推測されたのと同様に、(1)全てのマイクロカーネル法の実際の効率の悪さ、(2)これらのマイクロカーネルに実装された特定の概念、(3)これらの概念の特定の実装のためである。したがって、効率の良いマイクロカーネルを構成する解決法がある場合、以前の試みと異なり、正しい構成技術を適用する研究が残された。
一方、モノリシックカーネルの設計に通じる多段階保護領域のアーキテクチャは、保護の異なるレベル間で相互作用がある毎に(すなわち、プロセスが、データ構造をユーザモードとスーパバイザモード(supervisor mode)の両方で処理しなければならいときに)、重要性によってメッセージをコピーする必要があるので、重大な性能の低下を有している。殆どの研究者は、l990年代半ばまでに、注意深く調整することによって、このオーバヘッドを劇的に削減できるという考えを諦めたが、近年、より新しいマイクロカーネルは、性能を上げるために、最適化されている。
ハイブリッドカーネル(Hybrid kernel)
ハイブリッドカーネル法(hybrid kernel approach)は、モノリシックカーネルの速さ及び設計の容易さを、マイクロカーネルのモジュール性及び実行時の安全性と組み合わせることを試みたものである。
ハイブリッドカーネル法(hybrid kernel approach)は、モノリシックカーネルの速さ及び設計の容易さを、マイクロカーネルのモジュール性及び実行時の安全性と組み合わせることを試みたものである。
ハイブリッドカーネルは、本質的には、モノリシックカーネル法(monolithic kernel approach)とマイクロカーネルのオペレーティングシステム間の妥協案である。これは、従来のマイクロカーネルの性能におけるオーバヘッドを低減するために、幾つかのサービス(例えばネットワークスタック又はファイルシステム)はカーネル空間で動作させるが、カーネルコード(例えばデバイスドライバ)はユーザ空間のサーバとして動作させることを意味する。
ナノカーネル(Nanokernel)
ナノカーネルは、割込コントローラ、すなわちタイマのような最も基本的なサービスさえも含む全てのサービスを、実質的に、デバイスドライバに委ね(delegate)、カーネルに必要なメモリを、従来のマイクロカーネルよりも更に少なくしている。
ナノカーネルは、割込コントローラ、すなわちタイマのような最も基本的なサービスさえも含む全てのサービスを、実質的に、デバイスドライバに委ね(delegate)、カーネルに必要なメモリを、従来のマイクロカーネルよりも更に少なくしている。
エクソカーネル(Exokernel)
エクソカーネルは、ハードウェアを理論モデルに抽象化しない種類のカーネルである。論理モデルの代わりに、エクソカーネルは、物理的ハードウェアリソース、例えばCPU時間、メモリページ及びディスクブロックを異なるプログラムに割り当てる。エクソカーネル上で動作するプログラムは、エクソカーネルを用いて周知のOSの抽象化をシミュレートするライブラリオペレーティングシステムにリンクすることができ、あるいは、性能を高めるために、特定用途向けの抽象化を行うことができる。
エクソカーネルは、ハードウェアを理論モデルに抽象化しない種類のカーネルである。論理モデルの代わりに、エクソカーネルは、物理的ハードウェアリソース、例えばCPU時間、メモリページ及びディスクブロックを異なるプログラムに割り当てる。エクソカーネル上で動作するプログラムは、エクソカーネルを用いて周知のOSの抽象化をシミュレートするライブラリオペレーティングシステムにリンクすることができ、あるいは、性能を高めるために、特定用途向けの抽象化を行うことができる。
スケジューリング(Scheduling)
スケジューリングは、コンピュータのマルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプト(key concept)である。スケジューリングは、優先順位付きキュー(priority queue)の優先度を、プロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。
スケジューリングは、コンピュータのマルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプト(key concept)である。スケジューリングは、優先順位付きキュー(priority queue)の優先度を、プロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。
また、スケジューラは、リアルタイム環境、産業界における自動制御のためのモバイル機器(例えばロボティクス)では、プロセスがデッドラインに間に合うことを保証するようにしなければならない。これは、オペレーティングシステムを安定に保つためには重要である。スケジューリングされたタスクは、モバイル機器に送られて、管理用のバックエンド(administrative back end)によって管理される。
オペレーティングシステムのスケジューラの種類
オペレーティングシステムは、長期スケジューラ(別名、入力スケジューラ(admission scheduler))、中間的又は中期スケジューラ、及び短期スケジューラ(別名、ディスパッチャ(dispatcher))といった最大3つの異なる種類のスケジューラを備えることができる。
オペレーティングシステムは、長期スケジューラ(別名、入力スケジューラ(admission scheduler))、中間的又は中期スケジューラ、及び短期スケジューラ(別名、ディスパッチャ(dispatcher))といった最大3つの異なる種類のスケジューラを備えることができる。
長期スケジューラ、すなわち入力スケジューラは、どのジョブ又はプロセスを実行可能キューに入れるかを決定し、すなわち、長期スケジューラは、プログラムを実行しようとするとき、それを現在実行しているプロセスの組に直ちに追加するか、遅延して追加するかを決定する。したがって、この長期スケジューラは、オペレーティングシステム上でどのプロセスを動作させるかを決定する(dictate)とともに、同時にサポートする並列性の程度を決定し、すなわち、同時に実行するプロセスの数を多くするか少なくするか、処理するI/O負荷が高いプロセス(I/O intensive process)とCPU負荷が高いプロセス(CPU intensive process)とをどのように分けるかを決定する。通常、デスクトップコンピュータでは、このような長期スケジューラは存在せず、プロセスは、自動的にオペレーティングシステムに許可される。しかしながら、プロセスのデッドラインを間に合わせるオペレーティングシステムの能力は、オペレーティングシステムが問題なく処理できるプロセスの数よりも多くを許可することによって生じる処理速度の低下(slowdown)及び競合(contention)によって、低下するので、リアルタイムオペレーティングシステムでは、この種のスケジューリングが非常に重要である。
中期スケジューラは、仮想メモリを有する全てのオペレーティングシステムに存在し、プロセスを、メインメモリ(main memory)から2次メモリ(secondary memory、例えばディスクドライブ)に一時的に退避させ、また、これとは逆に、2次メモリからメインメモリに戻す。このような処理は、一般的に、スワップアウト(swapping out)とスワップイン(swapping in)と呼ばれる(不正確ではあるが、ページアウト(paging out)とページイン(paging in)とも呼ばれる)。中期スケジューラは、ある時間アクティブでないプロセス、優先度が低いプロセス、頻繁にページフォールトを起こしているプロセス、又は大量のメモリを確保しているプロセスを、スワップアウトして、メインメモリを他のプロセスに空け、後で、より多くのメモリが利用可能となったとき、あるいはプロセスのブロックが外されて、リソースを最早待たなくなったときに、これらのプロセスをスワップインして、メインメモリに戻すことを決定する。
今日の多くのオペレーティングシステム(スワップファイル以外に、仮想アドレス空間を補助記憶装置にマッピングすることをサポートしたオペレーティングシステム)では、中期スケジューラは、バイナリコードを実行するときに、バイナリコードをスワップアウトされたプロセスとして取り扱うことによって、実際には、長期スケジューラの役割を果たしている。このように、バイナリコードの一部が必要なときに、バイナリコードの一部は、要求があり次第、スワップインすることができ、又はゆっくりとロード(lazy loaded)することができる。
短期スケジューラ(別名、ディスパッチャ)は、クロック割込、I/O割込、オペレーティングシステムコール又は他の形式の信号の後、実行可能な状態でメモリ内にあるプロセスのうちのどのプロセスを次に実行する(CPUを割り当てる)かを決定する。したがって、短期スケジューラは、長期スケジューラ又は中期スケジューラに比べてより頻繁に、スケジューリングの決定を行う。スケジューリングの決定は、タイムスライス毎に、最小限、すなわち非常に短い時間で行う必要がある。この短期スケジューラは、スケジューラがCPUに他のプロセスを割り当てると決定したときに、CPUからプロセスを強制的に排除することができることを意味するプリエンプティブ(preemptive)であってもよく、あるいは、スケジューラがCPUからプロセスを除去することを強制できないノンプリエンプティブ(non-preemptive)であってもよい。
スケジューリング規則(scheduling disciplines)
スケジューリング規則は、同時且つ非同期でリソースを必要とするパーティ間に、リソースを割り当てるために用いられるアルゴリズムである。スケジューリング規則は、(スレッド及びプロセス間でCPU時間を共有する)オペレーティングシステムだけでなく、(パケットトラヒックを処理する)ルータにおいても用いられる。
スケジューリング規則は、同時且つ非同期でリソースを必要とするパーティ間に、リソースを割り当てるために用いられるアルゴリズムである。スケジューリング規則は、(スレッド及びプロセス間でCPU時間を共有する)オペレーティングシステムだけでなく、(パケットトラヒックを処理する)ルータにおいても用いられる。
スケジューリングアルゴリズムの主要な目的は、リソース飢餓(resource starvation)を最小にするとともに、リソースを利用するパーティ間で公平性を保証することである。
オペレーティングシステムにおけるスケジューラの実装
異なるコンピュータオペレーティングシステムは、異なるスケジューリング方式を実装している。MS−DOS及びマイクロソフトの非常に初期のWindowsシステムは、マルチタスクではなく、それ自体は、スケジューラを必要としなかった。Windows3.1ベースのオペレーティングシステムは、単純なノンプリエンプティブスケジューラ(non-preemptive scheduler)を使用しており、プログラマは、CPU時間を他のプロセスに与えるために、CPU時間を明け渡す(yield、CPUを解放する)ように、プロセスに命令することが必要であった。このノンプリエンプティブスケジューラは、マルチタスクを原始的にサポートしているが、より高度なスケジューリングの選択肢を備えていなかった。
異なるコンピュータオペレーティングシステムは、異なるスケジューリング方式を実装している。MS−DOS及びマイクロソフトの非常に初期のWindowsシステムは、マルチタスクではなく、それ自体は、スケジューラを必要としなかった。Windows3.1ベースのオペレーティングシステムは、単純なノンプリエンプティブスケジューラ(non-preemptive scheduler)を使用しており、プログラマは、CPU時間を他のプロセスに与えるために、CPU時間を明け渡す(yield、CPUを解放する)ように、プロセスに命令することが必要であった。このノンプリエンプティブスケジューラは、マルチタスクを原始的にサポートしているが、より高度なスケジューリングの選択肢を備えていなかった。
WindowsNT4.0ベースのオペレーティングシステムは、多段フィードバックキュー(multilevel feedback queue)を使用している。WindowsNT4.0ベースのオペレーティングシステムにおける優先度は、1〜31であり、1〜15の優先度は、ノーマル優先度であり、16〜31の優先度は、特権を割り当てる必要があるソフトリアルタイム優先度である。ユーザは、タスクマネージャアプリケーションから又はスレッド管理APIによって、これらの優先度から5段階の優先度を選択して、実行アプリケーションに割り当てることができる。
初期のUNIXシステムの実装では、多段フィードバックキューのスケジューラが使用されており、各フィードバックキュー内では、ラウンドロビン方式で選択を行っている(round robin selection)。このUNIXシステムでは、プロセスが生成されると、プロセスは、最優先キューに置かれ(新しいプロセス、例えば1回のマウスの移動又はキーストロークに関係したプロセスに対する応答時間を短くして)、UNIXシステム内でCPU時間を消費していくと、複数回に亘ってプリエンプト(preempt)され、最終的には、最低優先度のキューに入れられる。しかしながら、このUNIXシステムでは、新しいプロセスが絶え間なく生成されると、古いプロセスは、CPU時間の飢餓になる可能性があり、したがって、UNIXシステムが、新しいプロセスを生成速度よりも速く処理できない場合、飢餓を回避することはできない。UNIXシステムでは、プロセス優先度を40段階のうちの1つに明示的に設定できたが、最新のUNIXシステムでは、これ以上の数の優先度を利用することができる(Solarisは、160段階の優先度を有する)。優先度が低いプロセスの飢餓に対するWindowsNT4.0の解決法(プロセスが飢餓すると、このプロセスをラウンドロビンキューの先頭に上げる)とは異なり、初期のUNIXシステムは、巧妙な時間経過方式を用いており、すなわち、飢餓しているプロセスの優先度を、実行されるまで徐々に高め、プロセスが実行されると、優先度を、飢餓が始まる前の値にリセットする。
Linuxカーネルは、バージョン2.6.22までは、O(1)スケジューラ(O(1) scheduler)を用いていたが、このバージョン2.6.23からは、完全公平スケジューラ(Completely Fair Scheduler)に切り換えられている。
スケジューリングアルゴリズム
コンピュータ科学において、スケジューリングアルゴリズムは、システムリソース、通常はCPU時間に対するアクセスを、スレッド又はプロセスに与える方法である。スケジューリングアルゴリズムは、通常、システムに負荷を効率的に分散するために行われる。スケジューリングアルゴリズムの必要性は、マルチタスクを実行する、すなわち複数のプロセスを同時に実行する最新のオペレーティングシステムの殆どの要求から生じている。スケジューリングアルゴリズムは、通常、タイムスライス多重化カーネル(time slice multiplexing kernel)においてのみ用いられる。この理由は、システムに負荷を効率的に分散させるためには、タイムスライス多重化カーネルは、次のスレッドの実行を開始するために、現スレッドの実行を強制的に中断(suspend)できなければならない。
コンピュータ科学において、スケジューリングアルゴリズムは、システムリソース、通常はCPU時間に対するアクセスを、スレッド又はプロセスに与える方法である。スケジューリングアルゴリズムは、通常、システムに負荷を効率的に分散するために行われる。スケジューリングアルゴリズムの必要性は、マルチタスクを実行する、すなわち複数のプロセスを同時に実行する最新のオペレーティングシステムの殆どの要求から生じている。スケジューリングアルゴリズムは、通常、タイムスライス多重化カーネル(time slice multiplexing kernel)においてのみ用いられる。この理由は、システムに負荷を効率的に分散させるためには、タイムスライス多重化カーネルは、次のスレッドの実行を開始するために、現スレッドの実行を強制的に中断(suspend)できなければならない。
使用されるスケジューリングアルゴリズムは、循環リスト(cycling list)内の各プロセスに、所定の等しい時間(例えば1ms、通常は、1ms〜100ms)を与えるラウンドロビン方式のように簡単にすることができる。したがって、プロセスAが1ms間実行され、次にプロセスBが1ms間実行され、次にプロセスCが1ms間実行され、次にプロセスAに戻る。
より高度なスケジューリングアルゴリズムでは、プロセスの優先度、すなわちプロセスの重要度を考慮する。これにより、あるプロセスは、他のプロセスよりも長いCPU時間を使うことができる。なお、カーネルは、常に、オペレーティングシステムの適切な機能を保証するために必要とされる何らかのリソースを使用しており、したがって、無限の優先度を有すると言うことができる。対称型マルチプロセッサ(Symmetric Multiprocessor:SMP)システムでは、プロセッサアフィニティ(processor affinity)が、プロセス自体の動作速度を遅くする原因であっても、全体的なシステム性能を高めると考えられている。プロセッサアフィニティは、一般的に、キャッシュスラッシング(cache thrashing)を減少させることによって、性能を向上させる。
I/Oスケジューリング
この章は、I/Oスケジューリングに関する説明であり、I/Oスケジューリングは、プロセススケジューリングとは異なるものである。I/Oスケジューリングは、ブロックされたI/O動作をディスクサブシステムに送る順番を決定するために、コンピュータオペレーティングシステムで用いられる方法を記述する用語である。I/Oスケジューリングは、ディスクスケジューリング(disk scheduling)とも呼ばれる。
この章は、I/Oスケジューリングに関する説明であり、I/Oスケジューリングは、プロセススケジューリングとは異なるものである。I/Oスケジューリングは、ブロックされたI/O動作をディスクサブシステムに送る順番を決定するために、コンピュータオペレーティングシステムで用いられる方法を記述する用語である。I/Oスケジューリングは、ディスクスケジューリング(disk scheduling)とも呼ばれる。
目的
I/Oスケジューラ(I/O scheduler)は、I/Oスケジューラの目標に応じて、多くの目的を有することができ、以下、共通の目標を示す。
I/Oスケジューラ(I/O scheduler)は、I/Oスケジューラの目標に応じて、多くの目的を有することができ、以下、共通の目標を示す。
・ハードディスクのシークによって浪費される時間を最小にする。
・特定のプロセスのI/O要求を優先させる。
・ディスク帯域幅を動作中の各プロセスに割り当てる。
・特定のデッドラインの前に、ある要求が発行されることを保証する。
・特定のプロセスのI/O要求を優先させる。
・ディスク帯域幅を動作中の各プロセスに割り当てる。
・特定のデッドラインの前に、ある要求が発行されることを保証する。
実装
I/Oスケジューリングは、通常、ハードディスクによって機能しなければならず、ディスクヘッドを現在の位置から遠く離れた位置に移動する(この動作は、シークと呼ばれる)要求のために、アクセス時間が長くなるという特性を有する。このシーク動作がシステム性能に与える影響をできるだけ少なくするために、殆どのI/Oスケジューラは、ランダムな順番で入力された要求を、ディスク上で検出される順番に並べ替える種々のエレベータアルゴリズム(elevator algorithm)を実装している。
I/Oスケジューリングは、通常、ハードディスクによって機能しなければならず、ディスクヘッドを現在の位置から遠く離れた位置に移動する(この動作は、シークと呼ばれる)要求のために、アクセス時間が長くなるという特性を有する。このシーク動作がシステム性能に与える影響をできるだけ少なくするために、殆どのI/Oスケジューラは、ランダムな順番で入力された要求を、ディスク上で検出される順番に並べ替える種々のエレベータアルゴリズム(elevator algorithm)を実装している。
一般的なディスクスケジューリング規則
・ランダムスケジューリング(Random Scheduling:RSS)
・先入先出(First In, First Out:FIFO)、別名、先着順サービス(First Come First Served:FCFS)
・後入先出(Last In, First Out:LIFO)
・最短シーク順(Shortest seek first)、別名、最短シーク/サービス時間順(Shortest Seek / Service Time First:SSTF)
・エレベータアルゴリズム(Elevator algorithm)、別名、SCAN(その変種C−SCAN、LOOK及びC−LOOKを含む)
・一度にN個のレコードをスキャンするNステップSCAN(N-Step-SCAN)
・FSCAN、NがSCANサイクルの最初のキューサイズに等しいステップSCAN(Step-SCAN)
・完全公平キューイング(Completely Fair Queuing:CFQ(Linux))
・予測スケジューリング(Anticipatory scheduling)
・ランダムスケジューリング(Random Scheduling:RSS)
・先入先出(First In, First Out:FIFO)、別名、先着順サービス(First Come First Served:FCFS)
・後入先出(Last In, First Out:LIFO)
・最短シーク順(Shortest seek first)、別名、最短シーク/サービス時間順(Shortest Seek / Service Time First:SSTF)
・エレベータアルゴリズム(Elevator algorithm)、別名、SCAN(その変種C−SCAN、LOOK及びC−LOOKを含む)
・一度にN個のレコードをスキャンするNステップSCAN(N-Step-SCAN)
・FSCAN、NがSCANサイクルの最初のキューサイズに等しいステップSCAN(Step-SCAN)
・完全公平キューイング(Completely Fair Queuing:CFQ(Linux))
・予測スケジューリング(Anticipatory scheduling)
図1は、本発明の一実施の形態に基づくKOSスケジューラオペレーティングシステム(KOS scheduler operating system)100を示す概略図である。KOSスケジューラオペレーティングシステム100は、単一メモリ内で実行される複数のオペレーティングシステム101〜106を含み、全てのオペレーティングシステム101〜106は、外殻115で示すアプリケーションとインタフェースしている。
図2は、本発明の他の実施の形態に基づくKOSスケジューラオペレーティングシステム120を示す概略図である。KOSスケジューラオペレーティングシステム120は、単一メモリ内で実行される複数のオペレーティングシステム121〜126を含み、オペレーティングシステム121〜126は、外殻130で示すリソースとインタフェースしており、リソースは、外殻135で示すアプリケーションとインタフェースしている。
マルチOSのKOSシステム
マルチタスクにおいて、カーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大の数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。本発明は、この錯覚を、プロセッサの数を1つから2つ以上に増やすことによって現実のものとし、イベントを、リソースを要求するイベントとして、通信、スケジューリング、委託(delegated)、ルーティング及び外注(outsource)する特別に設計されたスケジューラソフトウェアを用いて、互いに同時に機能する、コンピュータシステムに実際に搭載されたオペレーティングシステムの数を増やすKOS設計を実際に提案する。通常、オペレーティングシステムが同時に動作させることができるプロセスの数は、搭載されているCPUの数に等しい(なお、プロセッサが同時マルチスレッディングをサポートしている場合は、この限りではない)。本発明の好ましい実施の形態は、複数のCPUが搭載されていることを必要とし、最大の性能を発揮するためには、協調して同時に機能するオペレーティングシステムの数が、搭載されているCPUの数に等しくなければならないことを、提案する。また、UNIX−KOS設計も、各オペレーティングシステムカーネル内でマルチスレッディングが実行され続けることを提案しているが、KOSスケジューラは、アプリケーションによって必要とされるリソース及び各オペレーティングシステムによってサポートされているリソースに基づいて、アプリケーションプログラムを、インストールされている各オペレーティングシステムに/から通信、外注及びルーティングすることが残されている。
マルチタスクにおいて、カーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大の数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。本発明は、この錯覚を、プロセッサの数を1つから2つ以上に増やすことによって現実のものとし、イベントを、リソースを要求するイベントとして、通信、スケジューリング、委託(delegated)、ルーティング及び外注(outsource)する特別に設計されたスケジューラソフトウェアを用いて、互いに同時に機能する、コンピュータシステムに実際に搭載されたオペレーティングシステムの数を増やすKOS設計を実際に提案する。通常、オペレーティングシステムが同時に動作させることができるプロセスの数は、搭載されているCPUの数に等しい(なお、プロセッサが同時マルチスレッディングをサポートしている場合は、この限りではない)。本発明の好ましい実施の形態は、複数のCPUが搭載されていることを必要とし、最大の性能を発揮するためには、協調して同時に機能するオペレーティングシステムの数が、搭載されているCPUの数に等しくなければならないことを、提案する。また、UNIX−KOS設計も、各オペレーティングシステムカーネル内でマルチスレッディングが実行され続けることを提案しているが、KOSスケジューラは、アプリケーションによって必要とされるリソース及び各オペレーティングシステムによってサポートされているリソースに基づいて、アプリケーションプログラムを、インストールされている各オペレーティングシステムに/から通信、外注及びルーティングすることが残されている。
KOS概念
分散カーネル動作スケジューラ(分散KOS)は、他のカーネル動作スケジューラと同期して動作する分散オペレーティングシステムである。各KOSは、他の同様なKOSと並列して動作し、ある所定のコンピュータシステム環境内には2つ以上のオペレーティングシステムがあり、ある特定のコンピュータには2つ以上のCPUが存在するが、これらの環境は、シングルコンピュータシステムとみなされる。幾つかの用語法(nomenclature)では、分散コンピューティング(distributed computing)とは、コンピュータリソース(computing resources)が多くの異なるコンピュータプラットフォームに分散され、全てのコンピュータリソースが、1つの主題の下に協調して(in concert)機能するものと定義される。KOSは、これに類似しているが、分散KOSは、シングルコンピュータシステム環境内にあり、互いに非常に密接し、シングルコンピュータシステムとして動作する点だけが異なる。各KOSは、単一カーネル内にある。各カーネルは、単一のスケジューラを有し、この単一スケジューラは、KOSが、イベントをスケジューリングする種類の他の同様のKOSと通信する通信機能を有するように設計された後は、このKOSによって置換される。
分散カーネル動作スケジューラ(分散KOS)は、他のカーネル動作スケジューラと同期して動作する分散オペレーティングシステムである。各KOSは、他の同様なKOSと並列して動作し、ある所定のコンピュータシステム環境内には2つ以上のオペレーティングシステムがあり、ある特定のコンピュータには2つ以上のCPUが存在するが、これらの環境は、シングルコンピュータシステムとみなされる。幾つかの用語法(nomenclature)では、分散コンピューティング(distributed computing)とは、コンピュータリソース(computing resources)が多くの異なるコンピュータプラットフォームに分散され、全てのコンピュータリソースが、1つの主題の下に協調して(in concert)機能するものと定義される。KOSは、これに類似しているが、分散KOSは、シングルコンピュータシステム環境内にあり、互いに非常に密接し、シングルコンピュータシステムとして動作する点だけが異なる。各KOSは、単一カーネル内にある。各カーネルは、単一のスケジューラを有し、この単一スケジューラは、KOSが、イベントをスケジューリングする種類の他の同様のKOSと通信する通信機能を有するように設計された後は、このKOSによって置換される。
データ処理は、一連のイベントに分割することができ、これによって、各イベントは、データ処理を完了するためには、ある程度のコンピュータリソースを必要とする。スケジューラは、CPU時間、リソース及び優先度をイベントに割り当てるタスクを有する、カーネル内で最も責任があるプログラムである。したがって、CPU時間のリソースを時分割シナリオ(time-sharing scenario)の下でスケジューリングする場合、特定のイベントには、その特定のイベントを完了するために必要とされるあらゆるリソースと、残りのリソース、例えばメモリ、一時的なI/Oバスの優先度等とが与えられる。本発明に基づくKOSは、シングルシステム当たり複数のKOSが存在するカーネル動作スケジューラであり、各KOSは、同時に動作するとともに、完了するためにコンピュータリソースを必要とする同時発生事象(simultaneous events)上での実行を管理する。更に、各KOSは、カーネル環境空間、あるいはこのようなリソースが制限又は不足しているときのメモリの共有部分内のセマフォによって制御される、同様のリソースを必要とする場合がある。分散OSであるKOS及びそのコアであるスケジューラは、汎用CPUハードウェアに結び付けられた分散コンピューティングであり、各分散OSは、初期化時に固有のIDを有し、このようなIDは、各KOSに割り当てられる。
UNIXシステムのIPC(Unix System IPC)
IPC機能及びプロトコルスタック(IPC Facilities and Protocol Stacks)
IPC機能及びプロトコルスタックは、UNIX構造に常駐し、ユーティリティとして既に統合されている。これらのユーティリティは、UNIX構造の下で、オペレーティングシステム間の通信を行うために、用いられる。
IPC機能及びプロトコルスタック(IPC Facilities and Protocol Stacks)
IPC機能及びプロトコルスタックは、UNIX構造に常駐し、ユーティリティとして既に統合されている。これらのユーティリティは、UNIX構造の下で、オペレーティングシステム間の通信を行うために、用いられる。
表1は、IPCの種類を、KOSがサポートする特定のリソースにマッピングした表である。表1の情報を参照すると、最初の行の7つのIPCの種類は、ローカルカーネル(local kernel)及びスケジューラオペレーティングシステム内のプロセス間の通信に用いられ、最後の2つの行は、同じコンピュータ上であるが、同じコンピュータシステム上の複数のCPUに分散されているオペレーティングシステム間の通信のために用いられる。
STREAMSのLinuxサポートは、「LIS」と呼ばれる独立したオプションのパッケージとして入手可能である。
表1の最初の行の7つのIPCの形式は、通常、同じホストオペレーティングシステム上のプロセス間のIPCに制限される。異なるホスト上のプロセス間のIPCのために一般的にサポートされるものは、最後の2つの行のソケット及びSTREAMSのみである。
カーネルスケジューラ
カーネルスケジューラは、現処理をどこで行うかを決定するために必要とされるリソースをフィルタリングし、選択する機能を有する。例えば、各CPUは、通常、汎用のCPUであり、それに対して、各KOSは、より特化されている。ポインタ及びファイル記述子(file descriptors)が、実際のファイルデータの代わりに、各KOS間で受け渡されるように、メモリの一部は、各KOS間で共有される。IPC機能を用いることによって、任意のプロセスを、複数のCPUに亘って、及び複数のKOSに亘って移動させることができ、したがって、必要なトランザクションを、プロセス間のトランザクションプロトコル(Transactional Protocol)の形式で移すことができる。
カーネルスケジューラは、現処理をどこで行うかを決定するために必要とされるリソースをフィルタリングし、選択する機能を有する。例えば、各CPUは、通常、汎用のCPUであり、それに対して、各KOSは、より特化されている。ポインタ及びファイル記述子(file descriptors)が、実際のファイルデータの代わりに、各KOS間で受け渡されるように、メモリの一部は、各KOS間で共有される。IPC機能を用いることによって、任意のプロセスを、複数のCPUに亘って、及び複数のKOSに亘って移動させることができ、したがって、必要なトランザクションを、プロセス間のトランザクションプロトコル(Transactional Protocol)の形式で移すことができる。
本発明の一実施の形態では、アプリケーション、例えば音声合成器は、プリエンプション(preemption)を許可するために割込、キューを禁止して、スワップアウトしなければならないときに、I/Oリソースの排他性を利用するKOSを用いた特定のCPU上で、連続して、したがって絶え間なく動作することができる。他の実施の形態では、アプリケーションは、DVDフォーマットのビデオストリーミングであり、ビデオストリーミングは、中央のOS(centralized OS)内のプロセス間で最適性を達成するために随時スワップアウトしなければならないシナリオに直面する中央のスケジューラ(centralized scheduler)に直面することなく、特定のCPU、メモリ及びKOSを利用して動作することができる。
共有メモリ
共有メモリは、現在のUNIX構造の非常に不可欠な部分であり、現在、特定の規則(particular convention)で使用するようになっているが、共有メモリは、また、KOS、現在の規則の下に、分散OSの目的で機能するように特定の方法で実装することができる。本発明の一実施の形態では、各オペレーティングシステムカーネルには、スケジューラが組み込まれており、スケジューラは、各カーネルの不可欠なキーコンポーネントプレーヤになっている。各分散オペレーティングシステムのKOSは、KOSスケジューラになっている。4つのこのようなスケジューラを有する4つのこのようなオペレーティングシステムがある場合、各スケジューラは、他のオペレーティングシステムの他のスケジューラと通信するように設計されている。この通信は、他のスケジューラのリソースを共有できるように設計されている。各スケジューラは、リソースの特定のセットに接続(attached)されており、この特定のセットには、典型的なコンピュータリソース、例えばディスクアクセス、インターネットアクセス、映画DVDプレーヤ、音楽DVD、キーボード通信等が含まれる。これらのリソースは、オペレーティングシステムのカーネルスケジューラの所定のセットに接続されており、スケジューラのそれぞれは、特定の所定の時点(specific given point)で、特別なリソースを必要とする特定の処理を、他のCPU上で動作している他のKOSに外注又はオフロード(off-load)することができる。各スケジューラには、メモリの一部が割り当てられる。スケジューラ及びそのカーネルは、他のKOSと共に、メインメモリ及びそれらのCPUにマッピングされている。
共有メモリは、現在のUNIX構造の非常に不可欠な部分であり、現在、特定の規則(particular convention)で使用するようになっているが、共有メモリは、また、KOS、現在の規則の下に、分散OSの目的で機能するように特定の方法で実装することができる。本発明の一実施の形態では、各オペレーティングシステムカーネルには、スケジューラが組み込まれており、スケジューラは、各カーネルの不可欠なキーコンポーネントプレーヤになっている。各分散オペレーティングシステムのKOSは、KOSスケジューラになっている。4つのこのようなスケジューラを有する4つのこのようなオペレーティングシステムがある場合、各スケジューラは、他のオペレーティングシステムの他のスケジューラと通信するように設計されている。この通信は、他のスケジューラのリソースを共有できるように設計されている。各スケジューラは、リソースの特定のセットに接続(attached)されており、この特定のセットには、典型的なコンピュータリソース、例えばディスクアクセス、インターネットアクセス、映画DVDプレーヤ、音楽DVD、キーボード通信等が含まれる。これらのリソースは、オペレーティングシステムのカーネルスケジューラの所定のセットに接続されており、スケジューラのそれぞれは、特定の所定の時点(specific given point)で、特別なリソースを必要とする特定の処理を、他のCPU上で動作している他のKOSに外注又はオフロード(off-load)することができる。各スケジューラには、メモリの一部が割り当てられる。スケジューラ及びそのカーネルは、他のKOSと共に、メインメモリ及びそれらのCPUにマッピングされている。
TCP/IPプロトコル群(TCP/IP Protocol Suite)
TCP/IPローカル(TCP and IP local)は、データ及びアプリケーションファイルをCPUとKOS間で転送するリソースとして用いることができる。各KOSは、それ自体のCPUに局所的であり、独立したメモリがマッピングされたI/Oを有していてもよく、有していなくてもよい。一実施の形態では、多くのUNIXシステムに常駐しているTCPポートのループバック機能(TCP Port loop-back facility)が用いられ、このTCPポートのループバック機能は、KOSシステム構成の下に他のオペレーティングシステムとの間でデータファイルを送受信するように構成されている。
TCP/IPローカル(TCP and IP local)は、データ及びアプリケーションファイルをCPUとKOS間で転送するリソースとして用いることができる。各KOSは、それ自体のCPUに局所的であり、独立したメモリがマッピングされたI/Oを有していてもよく、有していなくてもよい。一実施の形態では、多くのUNIXシステムに常駐しているTCPポートのループバック機能(TCP Port loop-back facility)が用いられ、このTCPポートのループバック機能は、KOSシステム構成の下に他のオペレーティングシステムとの間でデータファイルを送受信するように構成されている。
UDPプロトコルの機構(UDP Protocol Mechanics)
ユーザデータグラム(UDP:User datagram)、ユーザ定義プロトコル(user defined protocol)は、TCP/IPプロトコル群の一部であり、KOS規則の下に、独立したCPUとオペレーティングシステム間でデータファイルをインポート及びエクスポートするように構成することができる。また、UDPは、独立したCPUに常駐するオペレーティングシステム間でメッセージを受け渡すように構成することができる。
ユーザデータグラム(UDP:User datagram)、ユーザ定義プロトコル(user defined protocol)は、TCP/IPプロトコル群の一部であり、KOS規則の下に、独立したCPUとオペレーティングシステム間でデータファイルをインポート及びエクスポートするように構成することができる。また、UDPは、独立したCPUに常駐するオペレーティングシステム間でメッセージを受け渡すように構成することができる。
I/OCPUベースのオペレーティングシステム
I/Oバスコントローラは、特殊用途のデバイスとして機能するが、また、ディスクの動作、あるいはメインメモリの入力又は出力用のチャンネルデータの処理に関係した特定のタスクに固有のタスクを指示する(directs)。このようなコントローラは、より機能的な能力を有し、常駐ソフトウェア、例えばKOSが、ハードワイヤードな(hard wired)アプリケーションではなく、再構成可能なアプリケーションを特定のコントローラに提供することができる汎用のCPUによって、容易に置き換えることができる。本発明の実施の形態において、I/OCPU又はプロセッサは、一般のシステムのI/O機能のみを処理するように特に設計されたスケジューラを有するI/Oオペレーティングシステムを常駐させる。これによって、バスデータは、CPUが必要条件としてI/Oキューを形成する能力を有するので、コントローラにおけるボトルネックを回避することができる。
I/Oバスコントローラは、特殊用途のデバイスとして機能するが、また、ディスクの動作、あるいはメインメモリの入力又は出力用のチャンネルデータの処理に関係した特定のタスクに固有のタスクを指示する(directs)。このようなコントローラは、より機能的な能力を有し、常駐ソフトウェア、例えばKOSが、ハードワイヤードな(hard wired)アプリケーションではなく、再構成可能なアプリケーションを特定のコントローラに提供することができる汎用のCPUによって、容易に置き換えることができる。本発明の実施の形態において、I/OCPU又はプロセッサは、一般のシステムのI/O機能のみを処理するように特に設計されたスケジューラを有するI/Oオペレーティングシステムを常駐させる。これによって、バスデータは、CPUが必要条件としてI/Oキューを形成する能力を有するので、コントローラにおけるボトルネックを回避することができる。
表2は、特定のKOSの種類と、各種類のKOSがサポートするように特化された特定のリソースとを示している。例えば、表2は、メディアOS(第1列の第5行)が、例えばCD/DVD(第4列の第5行)を動作させたときに、ビデオI/Oを実行するように特化されていることを、示している。同様に、表2は、ディスクOS(第1列の第7行)が、例えばチャンネルバス(第2列の第7行)を介して通信するときに、ディスクI/Oを実行するように特化されていることを、示している。
本発明の一実施の形態では、オペレーティングシステムの機能が移動できるという概念(the concept of being portable)に基づく構成を用いており、オペレーティングシステムは、その機能を、それぞれが独立して動作するスレッドに分割することができる。この方法では、各スレッドは、異なる独立したスケジューラの下で、動作を他と関係なく実行する能力を有する。
状態遷移図に示す様々なプロセス状態は、状態間の可能な遷移が矢印によって示され、幾つかのプロセスは、メインメモリに記憶され、幾つかのプロセスは、2次(仮想)メモリに記憶される。
図3は、カーネルプロセススケジューリングの状態遷移200を示す図である。この状態遷移200は、「生成」状態("Created" state)201と、「実行待ち」状態("Waiting" state)207と、「実行」状態("Running" state)205と、「ブロック」状態("Blocked" state)209と、「スワップアウト及びブロック」状態("Swapped out and blocked" state)213と、「スワップアウト及び実行待ち」状態("Swapped out and waiting" state)211と、「終了」状態("terminated" state)203とを含んでいる。これらの状態の詳細については後述する。
本発明の実施の形態は、複数のオペレーティングシステムを、互いに協調させて機能させるとともに、それらが管理するリソースによって特化され、したがって、実行待ち状態を、「受信された」外注又はアウトルーティングされたイベントを入力するキューとして用いることによって、「スワップアウト及び実行待ち状態」及び「スワップアウト及びブロック状態」の必要性を排除している。本発明の実施の形態では、分散する(to be deployed)マルチスレッディング、スワップアウト及び実行待ち/ブロックを、現在の設計とは異なる設計を行う機能として分散する能力を残している。
主要なプロセス状態(Primary process states)
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに「記憶」される。
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに「記憶」される。
生成(Created)(「新たな(new)」とも呼ばれる)
プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。この状態では、プロセスは、「実行可能(ready)」状態に入る(admission)のを待っている。この入力(admission)は、長期スケジューラ、すなわち入力スケジューラによって、承認又は遅延される。通常、殆どのデスクトップコンピュータシステムでは、この入力は、自動的に承認されるが、リアルタイムオペレーティングシステムでは、この入力は、遅延される場合がある。リアルタイムオペレーティングシステム(real-time operating system:RTOS)では、「実行可能」状態に余りにも多くのプロセスを入れると、過飽和になり、システムリソースの競合が始まり、結果として、プロセスのデッドラインに間に合わなくなることを避けることができなくなる。
プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。この状態では、プロセスは、「実行可能(ready)」状態に入る(admission)のを待っている。この入力(admission)は、長期スケジューラ、すなわち入力スケジューラによって、承認又は遅延される。通常、殆どのデスクトップコンピュータシステムでは、この入力は、自動的に承認されるが、リアルタイムオペレーティングシステムでは、この入力は、遅延される場合がある。リアルタイムオペレーティングシステム(real-time operating system:RTOS)では、「実行可能」状態に余りにも多くのプロセスを入れると、過飽和になり、システムリソースの競合が始まり、結果として、プロセスのデッドラインに間に合わなくなることを避けることができなくなる。
実行可能(Ready)(「実行待ち(waiting)」又は「動作可能(runnable)」とも呼ばれる)
「実行可能」プロセス又は「実行待ち」プロセスは、既にメインメモリにロードされており、CPU上で実行されるのを待っている(ディスパッチャ、すなわち短期スケジューラによって、CPUにコンテキストスイッチが起こる)。システムの実行のある時点において、「実行可能」プロセスが数多くある場合がある。例えば、シングルプロセッサシステムでは、同時に実行できるプロセスの数は1つだけであり、他の全ての「同時実行(concurrently executing)」プロセスは、実行されることを待っている。
「実行可能」プロセス又は「実行待ち」プロセスは、既にメインメモリにロードされており、CPU上で実行されるのを待っている(ディスパッチャ、すなわち短期スケジューラによって、CPUにコンテキストスイッチが起こる)。システムの実行のある時点において、「実行可能」プロセスが数多くある場合がある。例えば、シングルプロセッサシステムでは、同時に実行できるプロセスの数は1つだけであり、他の全ての「同時実行(concurrently executing)」プロセスは、実行されることを待っている。
動作(running)(「活動(active)」又は「実行(executing)」とも呼ばれる)
「動作(running)」プロセス、「実行(executing)」プロセス又は「活動(active)」プロセスは、現在CPU上で実行されているプロセスである。この状態から、プロセスは、それに割り当てられたタイムスライスを超えると、オペレーティングシステムにより、コンテキストスイッチアウトされて、「実行可能」状態に戻される。なお、このプロセスは、完了又は終了され、あるいは幾つかの必要なリソース(例えば入出力リソース)によりブロックされて、「ブロック」状態に移行することもある。
「動作(running)」プロセス、「実行(executing)」プロセス又は「活動(active)」プロセスは、現在CPU上で実行されているプロセスである。この状態から、プロセスは、それに割り当てられたタイムスライスを超えると、オペレーティングシステムにより、コンテキストスイッチアウトされて、「実行可能」状態に戻される。なお、このプロセスは、完了又は終了され、あるいは幾つかの必要なリソース(例えば入出力リソース)によりブロックされて、「ブロック」状態に移行することもある。
ブロック(Blocked)(「スリープ(sleeping)」とも呼ばれる)
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されると、そのプロセスは、CPUから除去されて、ブロック状態になる。プロセスは、そのリソースが利用可能になるまで、「ブロック」されたままであり、最悪の場合には、デッドロック(deadlock)とされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、オペレーティングシステムが、プロセスが最早ブロックされていないことを知ると、プロセスは、再び「実行可能」状態になり、この実行可能状態から「実行」状態にディスパッチされることが可能になる。実行状態になってから、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されると、そのプロセスは、CPUから除去されて、ブロック状態になる。プロセスは、そのリソースが利用可能になるまで、「ブロック」されたままであり、最悪の場合には、デッドロック(deadlock)とされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、オペレーティングシステムが、プロセスが最早ブロックされていないことを知ると、プロセスは、再び「実行可能」状態になり、この実行可能状態から「実行」状態にディスパッチされることが可能になる。実行状態になってから、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
終了(Terminated)
プロセスは、「実行」状態から、その実行を完了させることによって、あるいは明示的に強制終了(kill)することによって、終了させることができる。何れの場合も、プロセスは、「終了」状態に移行する。この終了状態に入った後にも、プロセスがメモリから除去されない場合、このような状態は、「ゾンビ(zombie)」とも呼ばれる。
プロセスは、「実行」状態から、その実行を完了させることによって、あるいは明示的に強制終了(kill)することによって、終了させることができる。何れの場合も、プロセスは、「終了」状態に移行する。この終了状態に入った後にも、プロセスがメモリから除去されない場合、このような状態は、「ゾンビ(zombie)」とも呼ばれる。
更なるプロセス状態(Additional process states)
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらのプロセス状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらのプロセス状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
スワップアウト及び実行待ち(Swapped out and waiting)(「中断及び実行待ち(suspended and waiting)」とも呼ばれる)
仮想メモリをサポートしているシステムでは、プロセスは、スワップアウトすることができ、すなわち、プロセスは、中期スケジューラによって、メインメモリから除去されて仮想メモリに置かれる。そして、仮想メモリから、プロセスを、実行待ち状態にスワップバックすることができる。
仮想メモリをサポートしているシステムでは、プロセスは、スワップアウトすることができ、すなわち、プロセスは、中期スケジューラによって、メインメモリから除去されて仮想メモリに置かれる。そして、仮想メモリから、プロセスを、実行待ち状態にスワップバックすることができる。
スワップアウト及びブロック(Swapped out and blocked)(「中断及びブロック(suspended and blocked)」とも呼ばれる)
ブロックされているプロセスは、更に、スワップアウトされることもある。この事象(event)において、プロセスは、ブロックされた上にスワップアウトされており、スワップアウト及び実行待ちプロセスは、同じ状態にスワップバックすることができる(すなわち、この場合、プロセスは、ブロック状態に移行し、リソースが利用可能になるのを待っている)。
ブロックされているプロセスは、更に、スワップアウトされることもある。この事象(event)において、プロセスは、ブロックされた上にスワップアウトされており、スワップアウト及び実行待ちプロセスは、同じ状態にスワップバックすることができる(すなわち、この場合、プロセスは、ブロック状態に移行し、リソースが利用可能になるのを待っている)。
スケジューリング(Scheduling)
マルチタスクのカーネル(Linux等)では、複数のプロセスが常に存在することができ、各プロセスは、システム上でただ1つのプロセスであるかのように動作することができる。プロセスは、明示的に設計されない限り、他の如何なるプロセスも意識する必要はない。これにより、プログラムを容易に開発し、保守し、移植することができる。システム内の各CPUは、一度に、プロセス内の1つのスレッドしか実行することができないが、多くのプロセスからの多くのスレッドが同時に実行されているように見える。これは、スレッドが非常に短い時間動作するようにスケジューリングされ、そして、他のスレッドに動作の機会を与えるためである。カーネルのスケジューラは、スレッドのスケジューリングポリシを実施し、そこには、いつ、どれくらいの長さで、場合によっては(SMPシステム上の)どこでスレッドを実行できるかを含んでいる。通常、スケジューラは、それ自体のスレッドで動作し、このスレッドは、タイマ割込によって起動される。あるいは、このスレッドは、システムコール又はCPUを明け渡すことを望む他のカーネルスレッドによって呼び出される。スレッドは、ある程度の時間実行することが許され、そして、スケジューラスレッドへのコンテキストスイッチが起こり、続いて、スケジューラが選択するスレッドへの他のコンテキストスイッチが行われる。このサイクルは、繰り返され、この方法では、CPU使用のための特定のポリシが遂行される。
マルチタスクのカーネル(Linux等)では、複数のプロセスが常に存在することができ、各プロセスは、システム上でただ1つのプロセスであるかのように動作することができる。プロセスは、明示的に設計されない限り、他の如何なるプロセスも意識する必要はない。これにより、プログラムを容易に開発し、保守し、移植することができる。システム内の各CPUは、一度に、プロセス内の1つのスレッドしか実行することができないが、多くのプロセスからの多くのスレッドが同時に実行されているように見える。これは、スレッドが非常に短い時間動作するようにスケジューリングされ、そして、他のスレッドに動作の機会を与えるためである。カーネルのスケジューラは、スレッドのスケジューリングポリシを実施し、そこには、いつ、どれくらいの長さで、場合によっては(SMPシステム上の)どこでスレッドを実行できるかを含んでいる。通常、スケジューラは、それ自体のスレッドで動作し、このスレッドは、タイマ割込によって起動される。あるいは、このスレッドは、システムコール又はCPUを明け渡すことを望む他のカーネルスレッドによって呼び出される。スレッドは、ある程度の時間実行することが許され、そして、スケジューラスレッドへのコンテキストスイッチが起こり、続いて、スケジューラが選択するスレッドへの他のコンテキストスイッチが行われる。このサイクルは、繰り返され、この方法では、CPU使用のための特定のポリシが遂行される。
CPUバウンドなスレッド及びI/Oバウンドなスレッド(CPU- and I/O-bound Thread)
スレッドの実行は、CPUバウンドとI/Oバウンド(Input/Output bound)との何れかとなる傾向がある。すなわち、幾つかのスレッドは、計算を実行するために長い時間CPUを用い、他の幾つかのスレッドは、比較的遅いI/O動作を完了するために長い時間待機する。例えば、DNA配列スレッド(thread sequencing DNA)は、CPUバウンドである。文書処理プログラム(word processing program)の入力を行うスレッドは、人間がタイプするのを待つために多くの時間を費やすので、I/Oバウンドである。スレッドがCPUバウンドであるか、I/Oバウンドであるかは、常に明確でない。スケジューラが、何れのスレッドであるかを本当に考慮しても、スケジューラが行える最高のことは、推測することである。多くのスケジューラは、スレッドがCPUバウンドとみなすべきか否か、I/Oバウンドとみなすべきか否かについて検討し、したがって、スレッドをどちらか一方に分類する技術は、スケジューラにとって重要な要素である。スケジューラは、CPUにアクセスする優先権を、I/Oバウンドなスレッドに与える傾向がある。人間の入力を行うプログラムは、I/Oバウンドな傾向があり、最も速いタイピストであっても、各キーストローク間にかなりの時間がかかり、タイピストがインタラクトするプログラムは、この間は単に待っているだけである。人間が速やかな応答を期待してる場合、速度及び応答が遅いと、それに気付かれるので、人間とインタラクトするプログラムに優先度を与えることが重要である。
スレッドの実行は、CPUバウンドとI/Oバウンド(Input/Output bound)との何れかとなる傾向がある。すなわち、幾つかのスレッドは、計算を実行するために長い時間CPUを用い、他の幾つかのスレッドは、比較的遅いI/O動作を完了するために長い時間待機する。例えば、DNA配列スレッド(thread sequencing DNA)は、CPUバウンドである。文書処理プログラム(word processing program)の入力を行うスレッドは、人間がタイプするのを待つために多くの時間を費やすので、I/Oバウンドである。スレッドがCPUバウンドであるか、I/Oバウンドであるかは、常に明確でない。スケジューラが、何れのスレッドであるかを本当に考慮しても、スケジューラが行える最高のことは、推測することである。多くのスケジューラは、スレッドがCPUバウンドとみなすべきか否か、I/Oバウンドとみなすべきか否かについて検討し、したがって、スレッドをどちらか一方に分類する技術は、スケジューラにとって重要な要素である。スケジューラは、CPUにアクセスする優先権を、I/Oバウンドなスレッドに与える傾向がある。人間の入力を行うプログラムは、I/Oバウンドな傾向があり、最も速いタイピストであっても、各キーストローク間にかなりの時間がかかり、タイピストがインタラクトするプログラムは、この間は単に待っているだけである。人間が速やかな応答を期待してる場合、速度及び応答が遅いと、それに気付かれるので、人間とインタラクトするプログラムに優先度を与えることが重要である。
ラウンドロビンスケジューリングアルゴリズム(Round-Robin Scheduling Algorithm)
スケジューリングは、タスクに一連のリソースを割り当てるプロセスである。スケジューリングは、多くの分野、例えば計算プロセス及び生産プロセスにおいて、重要な概念である。
スケジューリングは、タスクに一連のリソースを割り当てるプロセスである。スケジューリングは、多くの分野、例えば計算プロセス及び生産プロセスにおいて、重要な概念である。
スケジューリングは、マルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプトである。スケジューリングは、優先順位付きキューの優先度をプロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。
汎用オペレーティングシステムでは、スケジューラの目的は、プロセッサの負荷をバランスさせ、何れか1つのプロセスが、プロセッサを独占し、且つリソースに飢餓することを防止することである。リアルタイム環境、例えば産業界における(例えばロボティクス用の)自動制御機器では、また、スケジューラは、プロセスがデッドラインに間に合うことができるように保証しなければならない。これは、システムを安定に保つためには重要である。
ラウンドロビン方式は、オペレーティングシステムにおけるプロセスのための最も簡単なスケジューリングアルゴリズムである。このアルゴリズムは、各プロセスに、タイムスライスを同じ長さで、順番に割り当てて、全てのプロセスが同じ優先度を有するように処理する。優先順位付きスケジューリング方式(prioritized scheduling system)では、優先度が等しいプロセスは、多くの場合、ラウンドロビン方式でアドレッシングされる。このアルゴリズムは、プロセス記述子ブロック(Process Descriptor Block:PDB)のリストの最初から開始して、タイムスライスが利用可能になったときに、CPUの機会を各アプリケーションに順番に与える。
ラウンドロビンスケジューリングは、ソフトウェアで実装することが簡単であるという優れた利点がある。オペレーティングシステムは、リストの最初に対する参照及び現アプリケーションに対する参照を有しなければならないので、次の要素に対するPDBの配置又はチェイン(array or chain)に続いて、次に何を動作すべきかを容易に決定することができる。一旦、配置の最後に到達すると、選択は、配置の最初に戻される。ブロックされたアプリケーションは、CPU時間を不必要に浪費し、更に悪いことには、実際にはもう少し待たなければならないときに、タスクに、そのリソースを見つけたと思わせるので、このブロックされたアプリケーションが不注意に選択されないことを保証するために、PDBを調べなければならない。「ラウンドロビン」という用語は、各個人が順番に何かを平等に分け合うという他の分野で知られているラウンドロビンの原理に由来している。
簡潔に言えば、各プロセスには、そのカンタム(quantum)と呼ばれる時間間隔が割り当てられ、この時間中、プロセスは、動作することができる。カンタムの終了後に、プロセスがまだ動作している場合、CPUは、プリエンプトされて、他のプロセスに与えられる。カンタムが経過する前に、プロセスがブロックされ、又は終了した場合、プロセスがブロックされたときに、CPUの切換が行われる。
スケジューリングアルゴリズムは、クロック割込をどのように処理するかについて、2つのカテゴリに分割することができる。
ノンプリエンプティブスケジューリング(Nonpreemptive Scheduling)
一旦、プロセスにCPUが与えられ、そのプロセスがCPUを持ち続ける場合は、スケジューリング規則は、ノンプリエンプティブである。ノンプリエンプティブスケジューリングの幾つかの特徴を以下に記す。
一旦、プロセスにCPUが与えられ、そのプロセスがCPUを持ち続ける場合は、スケジューリング規則は、ノンプリエンプティブである。ノンプリエンプティブスケジューリングの幾つかの特徴を以下に記す。
1.ノンプリエンプティブ方式では、短いジョブは、より長いジョブによって待たされるが、全てのプロセスの全体的な処理は公平である。
2.ノンプリエンプティブ方式では、入力最優先ジョブは、待っているジョブを移動することができないので、応答時間は予測しやすい。
3.ノンプリエンプティブスケジューリングでは、スケジューラは、以下の2つの局面でジョブを実行する。
a.プロセスが実行状態から実行待ち状態に切り換わったとき
b.プロセスが終了したとき
a.プロセスが実行状態から実行待ち状態に切り換わったとき
b.プロセスが終了したとき
プリエンプティブスケジューリング(Preemptive Scheduling)
一旦、プロセスにCPUを与えられても、CPUが取り上げられる可能性がある場合、スケジューリング規則は、プリエンプティブである。論理的には動作可能なプロセスを一時的に停止することを許可する戦略(strategy)は、プリエンプティブスケジューリングと呼ばれ、完了するまで動作させる(run to completion)方法と対照的である。
一旦、プロセスにCPUを与えられても、CPUが取り上げられる可能性がある場合、スケジューリング規則は、プリエンプティブである。論理的には動作可能なプロセスを一時的に停止することを許可する戦略(strategy)は、プリエンプティブスケジューリングと呼ばれ、完了するまで動作させる(run to completion)方法と対照的である。
ラウンドロビンスケジューリングは、(タイムスライスの最後では)プリエンプティブであり、したがって、システムが、対話型利用者(interactive users)に対して妥当な応答時間を保証する必要がある時分割環境(time-sharing environments)においては、有効である。
ラウンドロビン方式において、最も注目される問題は、カンタムの長さである。カンタムを余りにも短く設定すると、余りにも多くのコンテキストスイッチが起こり、CPU効率が下がる。一方、カンタムを余りにも長く設定すると、応答時間が遅くなり、先着順サービス(First Come First Served:FCFS)に近づく。この具体例を以下に示す。
タスク切換が2msであると仮定する。カンタムが8msである場合、非常に優れた応答時間を保証することができる。この具体例では、20人のユーザが全て、シングルCPUのサーバにログインしており、全てのユーザが同時に要求を生成する。各タスクは、10ms間(8msのカンタム+2msのオーバヘッド)かかり、20番目のユーザは、200ms(10ms×20)、すなわち1/5sで応答を得る。
一方、効率は、以下の通りである。
有効時間の総時間=8ms/l0ms=80%、すなわち、CPU時間の20%がオーバヘッドに浪費されている。
有効時間の総時間=8ms/l0ms=80%、すなわち、CPU時間の20%がオーバヘッドに浪費されている。
200msのカンタムでは、効率は、200ms/202ms=約99%である。
しかしながら、応答時間については、20人のユーザが同時に要求を行った場合、202×20=4040ms、すなわち4s以上となり、これは好ましくない。実際に起こっていることの全体像を得るために、パラメータを定義する。
・応答時間−プロセスが完了する時間。OSは、ある種のプロセスを好み、又は平均待ち時間のような統計的特性を最小にすることを望む。
・実行時間(Implementation Time)−これは、アルゴリズム及び保守の複雑性を含む。
・オーバヘッド−どのプロセスをスケジューリングするかを決定し、この選択のために必要とされるデータを収集する時間。
・公平性−ユーザプロセスを異なって処理する程度の差。
・応答時間−プロセスが完了する時間。OSは、ある種のプロセスを好み、又は平均待ち時間のような統計的特性を最小にすることを望む。
・実行時間(Implementation Time)−これは、アルゴリズム及び保守の複雑性を含む。
・オーバヘッド−どのプロセスをスケジューリングするかを決定し、この選択のために必要とされるデータを収集する時間。
・公平性−ユーザプロセスを異なって処理する程度の差。
したがって、カンタムを長くすると、効率が良くなることを保証し、カンタムを短くすると、応答時間が短くなることを保証する。スループット及びターンアラウンド(turnaround)は、システム内のジョブの数及び1タスク当たりのI/Oの使用量に依存する。ラウンドロビン方式は、明らかに公平である。
いずれにしても、ラウンドロビンスケジューリングの下での平均待ち時間は、多くの場合、非常に長く、プロセスは、そのタイムスライスよりも短い時間を使用する場合がある(例えば、セマフォ又はI/O動作のブロッキング)。アイドルタスクは、動作している他のタスクがないとき以外は、決してCPUを獲得してはならない(アイドルタスクは、ラウンドロビンに参加してはならない)。
最新の主要なオペレーティングシステムは、ラウンドロビンの変形で動作し、これらがもたらす最も重要な改良は、プロセスの優先順位クラス(priority classes)である。
これらのクラスを設定する簡単なアルゴリズムは、最後のカンタムのうちのプロセスが使用した割合(fraction)をfとすると、優先度を1/fに設定することである。その100msのうちの2msだけを使用したプロセスは、優先度(priority level)が50となり、ブロッキングの前に50msを使用したプロセスは、優先度が2となる。したがって、100msのカンタム全体を使用したプロセスは、最下位優先度になる(優先度を1〜99に設定するLinuxとは異なり、優先度がC−スタイル[0・・・99]である他のシステムでは、1になる)。
KOSスケジューラのオペレーティングシステムの設計には、明らかに3つの構成がある。図1は、他の全ての従来のオペレーティングシステムと同様に、リソースが外側の周辺に沿って分布するクローズクラスタKOS構成(close cluster KOS configuration)を示している。
図4は、KOS概念設計の下で可能である幾つかの追加機能を有するシステム300を示している。これらの追加機能には、入力機構からのイベントを受信して、イベントを、リソースへのアクセスを得る適切な配信OS(distribution OS)にルーティングする目的だけに専用の中央に位置するルーティングOS機能(central routing OS facility)301が含まれる。この設計の下では、各オペレーティングシステム310〜316は、それに割り当てられた各イベントの完全な解決(full resolution)を得るために直ちに達することができるそのメモリ使用量(footprint)内に組み込まれた限られた数のリソースを有する。外側の周辺には、システムリソースとみなすことができる更なるリソースがあり、内部の各OS310〜316は、これらのリソースを、共有しなければならないが、拡張イベント(完了のためにリソースを拡張する必要があるジョブ)のために確保することができる。
また、図4に示すように、システム300は、OS機能301を取り囲む複数のオペレーティングシステム310〜316を備える。図4では、オペレーティングシステム310〜316は、リソース330の外殻によって囲まれており、次に、リソース330は、アプリケーション340の外殻によって囲まれている。
カーネル動作スケジューラの構成の1つの方法は、スター構成(Star Configuration)である。スター構成の下では、1つのカーネルが中央のディスパッチャ(central dispatcher)として機能するように構成されており、実行可能状態からプロセスを受信する役割は、必要なリソース、例えば追加的なメモリ割当、スタック要求、ロバストなI/Oトラヒック等のためにプロセスをスクリーニングし、このプロセスを、このような要求をサポートするように構成された適切なオペレーティングシステム環境にディスパッチすることである。スター構成の下では、如何なるプロセスもブロック、すなわちスリープされず、トラヒックは、実行状態、実行待ち状態及び切換状態(switched state)のみの3つの状態を用いて流れる。
システムS1内のスターコアカーネル構成(Star Core Kernel Configuration)
コアとして機能するカーネルは、n個の他のカーネルによって囲まれている。図5は、本発明の一実施の形態に基づくシステムS1内のスターコアカーネル構成350を示している。このスターコアカーネル構成350は、KOSを有する中央ルーティングオペレーティングシステム(Central Routing Operating System)360を備え、この中央ルーティングオペレーティングシステム360は、カーネルオペレーティングシステム(kernel operating system)351〜356によって囲まれており、これらのカーネルオペレーティングシステム351〜356は、アプリケーション363の外殻によって囲まれている。各オペレーティングシステム351〜356を囲む外殻は、各オペレーティングシステム351〜356が利用可能なリソースに対応している。中央ルーティングオペレーティングシステム360は、以下の典型的なプロセス状態を取る。
コアとして機能するカーネルは、n個の他のカーネルによって囲まれている。図5は、本発明の一実施の形態に基づくシステムS1内のスターコアカーネル構成350を示している。このスターコアカーネル構成350は、KOSを有する中央ルーティングオペレーティングシステム(Central Routing Operating System)360を備え、この中央ルーティングオペレーティングシステム360は、カーネルオペレーティングシステム(kernel operating system)351〜356によって囲まれており、これらのカーネルオペレーティングシステム351〜356は、アプリケーション363の外殻によって囲まれている。各オペレーティングシステム351〜356を囲む外殻は、各オペレーティングシステム351〜356が利用可能なリソースに対応している。中央ルーティングオペレーティングシステム360は、以下の典型的なプロセス状態を取る。
1.システムS1内でプロセスが最初に生成されたとき、プロセスは、それが必要なリソースのためにスクリーニングされる新たなプロセス状態(new process state)となる(システムリソースに関する章参照)。一旦、必要なリソースが決定されると、コアは、これらのリソース条件(resource requirement)を満たしそうな、例えばI/Oオペレーティングシステム(I/Oオペレーティングシステム参照)のようなオペレーティングシステム(理想的にはアイドル状態にある)を調べる。一旦、適切なOSが決定されると、プロセスは、(通常、実行可能状態から)切換状態に移行し、クロックの次のサイクルで、プロセスは、システムS1内の適切なオペレーティングシステムにディスパッチされる。
2.コアは、既にディスパッチされて、現在動作中であるべきプロセスに基づいて、他の全ての実行状態と通信するために使用される「実行状態」を有する。コアの実行状態は、実際にはプロセスを動作させないが、システムS1内の全ての実行プロセス(running processes)の経過を追跡して、各状態をコンソールに通知する像通信状態(statue communication state)又は仮想実行状態である。
3.まさに生成されたプロセスの実行可能状態は、優先順位の決定状態(triage state)又はスクリーニング状態(screening state)として機能するスターコアカーネルの下にある状態であり、スターコアカーネルの下にある周辺カーネル(peripheral kernel)の何れにおいても、周辺カーネルは、従来のプロセス状態の下にあるのと同様に、実行待ち状態又は動作可能状態(runnable state)として機能する。
図6は、通信チャンネルC680を介して通信する複数のカーネル601、630、640のハイレベルのブロック図であり、各カーネルは、スイッチアウトするアプリケーションプログラムAと、スイッチインするアプリケーションプログラムBとを有する。例えば、カーネル601は、中央演算処理装置602によって実行され、スケジューラ607を含み、KOS610は、実行状態611と、実行待ち状態612と、アプリケーションプログラムA615を切り換える切換状態613とを有する。図6は、スイッチアウトするアプリケーションA615と、スイッチインするアプリケーションB605とを示している。カーネル630、640は、カーネル601と同様に動作するので、これ以上は説明しない。通信チャンネルC680は、複数のCPUに亘って、カーネル601、630、640の内部のKOSスケジューラ間を結んでいる。
共有メモリ(Shared Memory)
図7は、共有メモリΣ1720、Σ2721、Σ3722、Σ4723と、オペレーティングシステム710〜713の環境とを含むシステム700を示している。図7に示すように、共有メモリΣ1720〜Σ4723は、まさに、UNIXオペレーティングシステムの一部であり、抽象化(abstract)は、現在、特定の規則で使用するように提供されているが、共有メモリΣ1720〜Σ4723は、本発明の実施の形態に基づく分散オペレーティングシステムの目的を果たすように、特定の方法で実装することができる。各オペレーティングシステムカーネルが専用のスケジューラとなり、これらの専用のスケジューラを有する4つのこのようなオペレーティングシステム710〜713がある場合、各スケジューラが他のスケジューラのリソースを共有することができるという方法によって、他のスケジューラと通信するように、スケジューラは設計されている。各スケジューラは、初期化(起動)のときに、他のスケジューラに知られている特定のリソースに接続する(attached)場合、その動作の任意の時点で、それが供給するリソースのカテゴリの一部でない動作を、他のスケジューラに外注することができる。
図7は、共有メモリΣ1720、Σ2721、Σ3722、Σ4723と、オペレーティングシステム710〜713の環境とを含むシステム700を示している。図7に示すように、共有メモリΣ1720〜Σ4723は、まさに、UNIXオペレーティングシステムの一部であり、抽象化(abstract)は、現在、特定の規則で使用するように提供されているが、共有メモリΣ1720〜Σ4723は、本発明の実施の形態に基づく分散オペレーティングシステムの目的を果たすように、特定の方法で実装することができる。各オペレーティングシステムカーネルが専用のスケジューラとなり、これらの専用のスケジューラを有する4つのこのようなオペレーティングシステム710〜713がある場合、各スケジューラが他のスケジューラのリソースを共有することができるという方法によって、他のスケジューラと通信するように、スケジューラは設計されている。各スケジューラは、初期化(起動)のときに、他のスケジューラに知られている特定のリソースに接続する(attached)場合、その動作の任意の時点で、それが供給するリソースのカテゴリの一部でない動作を、他のスケジューラに外注することができる。
各スケジューラには、メモリの、他のスケジューラと共有する一部が割り当てられており、完了するためにアクセスして処理するデータセットによって動作するプログラムを必要とする動作を、他のスケジューラに外注する場合、外注スケジューラは、量があるデータ自体ではなく、ポインタ及びファイル記述子だけを受信スケジューラに渡す。ポインタ及びファイル記述子は、そのCPUで処理する受信スケジューラ上のキューに入れることができる。
IPC機能及びプロトコルスタック(IPC Facilities and Protocol Stacks)
プロトコルスタックだけでなく、IPC機能も、UNIX構造とは別に設けられており、これらの両方は、既にユーティリティとして統合されている。また、これらのユーティリティは本発明にも有用である。これらのユーティリティは、幾つかのプラットフォームに亘ってではなく、特定のコンピュータシステムに組み込む現在の分散コンピューティングを除いて、クラスタ内のオペレーティングシステム間で通信を大量に行うように意図された形で構成することができる。
プロトコルスタックだけでなく、IPC機能も、UNIX構造とは別に設けられており、これらの両方は、既にユーティリティとして統合されている。また、これらのユーティリティは本発明にも有用である。これらのユーティリティは、幾つかのプラットフォームに亘ってではなく、特定のコンピュータシステムに組み込む現在の分散コンピューティングを除いて、クラスタ内のオペレーティングシステム間で通信を大量に行うように意図された形で構成することができる。
IPCスケジューラ(IPC Scheduler)
図8は、ネットワークコントローラを1つのリソースとして示しており、データパケット751がネットワークオペレーティングシステム(network operating system:NOS)755に送信されている。図8に示すように、カーネルスケジューラは、リソースプロセスを確保する(acquisition)フィルタを備え、カーネルスケジューラは、まず、プロセスがどこで発生すべきかを判定するために必要とされるリソースを選択する。各CPUは、汎用CPUであり、各オペレーティングシステムのカーネルは、リソースのグループ又はセットの割当に、より特化又は専用とされる。図8は、本発明に基づいて用いられる、特化又は専用とされたオペレーティングシステムの一実施の形態を示している。NOS755は、FTP、PPP、Modem、Airport、TCP/IP、NFS及びAppletalk等のプロトコルのうちの1つ以上を用いることができ、また、プロキシのオプション(Proxy options)によって、ポートを用いることができる。
図8は、ネットワークコントローラを1つのリソースとして示しており、データパケット751がネットワークオペレーティングシステム(network operating system:NOS)755に送信されている。図8に示すように、カーネルスケジューラは、リソースプロセスを確保する(acquisition)フィルタを備え、カーネルスケジューラは、まず、プロセスがどこで発生すべきかを判定するために必要とされるリソースを選択する。各CPUは、汎用CPUであり、各オペレーティングシステムのカーネルは、リソースのグループ又はセットの割当に、より特化又は専用とされる。図8は、本発明に基づいて用いられる、特化又は専用とされたオペレーティングシステムの一実施の形態を示している。NOS755は、FTP、PPP、Modem、Airport、TCP/IP、NFS及びAppletalk等のプロトコルのうちの1つ以上を用いることができ、また、プロキシのオプション(Proxy options)によって、ポートを用いることができる。
なお、メモリは、4つ(quadrant)に分割され、メモリの一部は、各オペレーティングシステム間で分割され、ポインタ及びファイル記述子は、大量のデータを移動するのではなく、割当によってオペレーティングシステムからオペレーティングシステムに渡すことができることは、明らかである。IPC機能を用いることにより、プロセスは、必要なトランザクションを運ぶためのメッセージを、トランザクションプロトコルの形式で通信することができる。
一実施の形態においては、アプリケーション、例えば音声合成器は、プロセスを中断する割込なしで、特定のI/OOSを利用するCPU上で連続して動作することができる。他の実施の形態においては、アプリケーション、例えばビデオストリームは、特定のCPUと、メモリと、プログラムをその寿命中にスワップイン及びスワップアウトするスケジューラによって制御されることがないOSとを利用して、動作することができる。
図9は、本発明の一実施の形態に基づくKOS790を示しており、KOS790は、プロセスを、I/Oキー781と、AOSサウンドシステム782と、I/Oビデオ783と、I/Oディスク784と、I/Oユニバーサルシリアルバス(USB)785と、I/O補助ポート786と、プリントOS787と、I/Oネットコントローラ788とに割り当てるために用いられる。図9に示すように、I/OUSBバス785は、コントローラを有し、コントローラは、そのバス上のリソースのマネージャである。リソースは、データをバスに沿って双方向に移動させるために必要である。I/Oは、あらゆるコンピュータの主要な機能であるので、最早オペレーティングシステムの副機能ではない。本発明の実施の形態では、オペレーティングシステムは、非同期だけではなく、並列して動作する複数の下位のオペレーティングシステムを調整する。
I/Oオペレーティングシステム
I/Oオペレーティングシステムは、集中化された非同期中央OS(centralized asynchronous central OS)からのデータ読出を実行して、何時、どのようにデータを転送するかを決定するコントローラ機能を実行する。
I/Oオペレーティングシステムは、集中化された非同期中央OS(centralized asynchronous central OS)からのデータ読出を実行して、何時、どのようにデータを転送するかを決定するコントローラ機能を実行する。
本発明に基づく構成(construct)は、スレッドに分割されたその機能を有することができる、移動可能(portable)であるという概念に基づくオペレーティングシステムの機能に分散され、そこでは、スレッドは、プロセスに類似しているが、他のスレッドコード(threads code)、データ及び他のリソースを共有することができる。
図10に示す一実施の形態における構成(construct)は、1つのオペレーティングシステムの機能801、803、805、807、812、814を分散し(deploy)、システムコールの全ては、スレッディングされた通信(threaded communication)を用いて互いに動作する非同期オペレーティングシステム(asynchronous operating system)810、816を形成する。それ自体の独立したカーネルを有する各オペレーティングシステムは、2つの特化された機能及びキュー管理のために特別に設計されている。この構成(arrangement)は、全てのタスクをコンピュータの回りに分散させることによって、サイクルタイムを分割し、複数のCPUを利用する。各カーネルは、それぞれ1つのCPUに結び付けられており、コントローラは、CPU又は特殊用途のコントローラによって置換される。
主要なKOSプロセス状態(Primary KOS process states)
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに記憶される。
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに記憶される。
生成(「新たな」とも呼ばれる)
アプリケーションが開かれて、プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。このアプリケーション状態では、プロセスは、「実行可能(ready)」状態に入るのを待っている。この入力は、長期スケジューラ、すなわち入力スケジューラ、KOSスケジューラによって、承認又は遅延される。入力する間に、プロセスは、必要とされるリソースが調べられた後、実行状態に入り、あるいは、プロセスは、動作に必要とされる適切なリソースを有する他のCPUのオペレーティングシステムに切り換えられる切換状態に再設定される。
アプリケーションが開かれて、プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。このアプリケーション状態では、プロセスは、「実行可能(ready)」状態に入るのを待っている。この入力は、長期スケジューラ、すなわち入力スケジューラ、KOSスケジューラによって、承認又は遅延される。入力する間に、プロセスは、必要とされるリソースが調べられた後、実行状態に入り、あるいは、プロセスは、動作に必要とされる適切なリソースを有する他のCPUのオペレーティングシステムに切り換えられる切換状態に再設定される。
実行可能(実行待ち)
この実行可能状態は、上述した主要なプロセス状態の「実行可能」状態と同様である。
この実行可能状態は、上述した主要なプロセス状態の「実行可能」状態と同様である。
動作(Running)
この動作状態は、上述した主要なプロセス状態の「動作」状態と同様である。
この動作状態は、上述した主要なプロセス状態の「動作」状態と同様である。
切換(以前は「ブロック」又は「スリープ(sleeping)」と呼ばれていた)
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されるのではなく、(ブロックプロセスは、実行を続けることができないので)、プロセ
スは、現在のCPU及びオペレーティングシステムから除去されて、ブロック状態になり、プロセスが必要とするリソースが連続して利用可能な他のCPU及びオペレーティングシステムに移される。シングルCPU/シングルOSのシナリオの下では、プロセスは、そのリソースが利用可能になるまで、ブロックされたままであり、最悪の場合には、デッドロックされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、プロセスが、そのリソースが利用可能な適切なオペレーティングシステムに到着すると、プロセスは、再び「実行可能」状態に入り、この「実行可能」状態からその「実行」状態にディスパッチされ、この「実行」状態から、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されるのではなく、(ブロックプロセスは、実行を続けることができないので)、プロセ
スは、現在のCPU及びオペレーティングシステムから除去されて、ブロック状態になり、プロセスが必要とするリソースが連続して利用可能な他のCPU及びオペレーティングシステムに移される。シングルCPU/シングルOSのシナリオの下では、プロセスは、そのリソースが利用可能になるまで、ブロックされたままであり、最悪の場合には、デッドロックされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、プロセスが、そのリソースが利用可能な適切なオペレーティングシステムに到着すると、プロセスは、再び「実行可能」状態に入り、この「実行可能」状態からその「実行」状態にディスパッチされ、この「実行」状態から、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
終了(Terminated)
この終了状態は、上述した主要なプロセス状態の「終了」状態と同様である。
この終了状態は、上述した主要なプロセス状態の「終了」状態と同様である。
更なるプロセス状態(Additional process states)
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらの状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらの状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
スワップアウト及び実行待ち(Swapped out and waiting)
このスワップアウト及び実行待ち状態は、上述した主要なプロセス状態の「スワップアウト及び実行待ち」状態と同様である。
このスワップアウト及び実行待ち状態は、上述した主要なプロセス状態の「スワップアウト及び実行待ち」状態と同様である。
スワップアウト及びブロック(Swapped out and blocked)
このスワップアウト及びブロック状態は、上述した主要なプロセス状態の「スワップアウト及びブロック」状態と同様である。
このスワップアウト及びブロック状態は、上述した主要なプロセス状態の「スワップアウト及びブロック」状態と同様である。
図11は、通知可能なプロトコル(signaling enabled protocols)を示している。例えば、プロトコルKCは、複数のカーネル、すなわちKDISPLAY852と、KI/OFile System1853と、KAPPS1854と、KCONTROL855と、KBUS CONTROL856とを同期させるのに用いることができる。非同期で機能する3つ以上のカーネルを、動作環境において中央及びコアのカーネルによって同期させる方法について説明する。UNIXオペレーティングシステムは、通常カーネルとして知られているコアからなり、カーネルは、中央コマンド(central commands)の全てを実行し、動作を実行するあるタスクを実行する複数の処理又はノードを、動作環境に亘って分散する。ここに説明する方法は、これとは異なり、まず、中央のコアカーネル(central core kernel)が、全ての入力及び出力動作の大部分をI/Oカーネルに外注できるようにし、次に、I/Oカーネルは、中央のカーネル(central kernel)又はコアに更なる負担をかけることなく、このような動作の残り部分を実行する。
オペレーティングシステム内では、ファイルI/O、すなわちメモリへ/からのデータ転送が、従来のカーネルの大部分の動作を占め、このような負荷が大きいタスクから従来のカーネルを解放することができるとき、カーネルによって実行されるI/O動作、例えばアプリケーションの管理並びにコマンドの解釈、及び他のコア構成、例えば特定のCPU上での処理時間のスケジューリングは、より少ない待ち時間で完了することができる。
この方法は、中央の階層的カーネルと、幾つかの下位の及び/又は非同期カーネルとの動作間のタスク分離を記述している。対称カーネル(symmetric kernel)が共有情報を非同期で処理する対称カーネル処理環境では、このような環境の不一致の下で起こり得る衝突を制御し、指示する環境変数(environmental variable)を用いている。また、この方法は、対称的、抽象的、且つ車輪のような装置(symmetric metaphysical wheel-like apparatus)上の複数の回転カーネル(rotating kernel)を記述しており、全ての回転カーネルは、カーネルとそれが動作するコマンド及びデータ間の衝突を制御するために用いる環境変数を介して、情報を共有している。
通信プロトコル(COMMUNICATION PROTOCOL)
本発明の実施の形態においては、通信プロトコルは、環境の下で動作するカーネル間の通信及びこれらのカーネルの下で動作するプロセス間の通信プロトコルとして定義される。この通信プロトコルにより、3つ以上のプロセスが存在することができ、アドレッシングする特定の種類の通信の外部にあるプロセスによって管理される通信によって、これらのプロセス間で同時に通信することができる。通信プロトコルは、構成アーキテクチャ(configuration architecture)の種類に応じて、異なった設計を行うことができる。
本発明の実施の形態においては、通信プロトコルは、環境の下で動作するカーネル間の通信及びこれらのカーネルの下で動作するプロセス間の通信プロトコルとして定義される。この通信プロトコルにより、3つ以上のプロセスが存在することができ、アドレッシングする特定の種類の通信の外部にあるプロセスによって管理される通信によって、これらのプロセス間で同時に通信することができる。通信プロトコルは、構成アーキテクチャ(configuration architecture)の種類に応じて、異なった設計を行うことができる。
プロセスは、プロセス間の通信のテーブルの代わりに、通信ポートに並ぶ(line up)。図12に示すように、プロセス911〜916の全ては、通信ポート910にアクセスしようとしている。プロセスマネージャは、プロセス間の通信を、要求及びリソースが解放されるとして、管理する。標準のIPCテーブル構成(standard IPC table configuration)に比べて、このポートのような通信プロセスによって提供される多くの利点のうちの1つは、2つ以上のプロセスが同時に通信できるということである。他の利点は、ハンドシェークという抽象概念(handshake abstract)ではなく、プロセス間のプロトコルによって全ての通信が管理されるということである。6つ以上のプロセスが互いの間の通信を確立するために並ぶとき、各プロセスは、それ自体と、1つ以上の他のプロセスとの間のダイレクトライン(direct line)を確立しなければならない。
例えば、図12において、プロセス911は、リソースAを解放しようとしており、プロセス912は、リソースAを要求しようとしている。通信は、プロセス911とプロセス912間で確立され、これによって、プロセス911、912は、リソースAに関する共有関係(shared relationship)を有し、リソースAは、2つのプロセス911、912間の通信を行うプロセスマネージャによって管理される。プロセス911及びプロセス912の両方が、所定のシナリオの下でリソースCを要求する場合であって、プロセス911がリソースCを要求しながら、リソースAを解放し、プロセス915がリソースCの解放に至っていない場合、プロセス912の要求は、プロセス911がリソースCを入手し、これを解放するまで、ブロックされる。この所定のシナリオは、リソースを要求しているプロセスが多くあり、利用可能なリソースが適切な数よりも少ないという事実によって支配されている。
以下に説明するマネージャは、以下に限定されるものではないが、関係マネージャ、プロセッサマネージャ(Processor Manager)、スレッドマネージャ(Thread Manager)、リソースマネージャ及びリソース割当マネージャ(Resource Allocation manager)を含み、これらは全て、本発明に基づくKOSの実施の形態に使用される。以下では、これらのマネージャ及びKOSの他のコンポーネントがどのように機能するかを説明する。
関係マネージャ(RELATIONSHIP MANAGER)
関係マネージャは、常に、環境内で動作する複数のカーネル間の関係を管理する。各カーネルによって、多くの所定のスレッドがそれらのカーネルコードを実行する役割を果たすことができるが、この要素は、関係マネージャによって実行されるタスクには関係ない。本発明の実施の形態に基づく関係マネージャによって実行されるタスクは、カーネルと、カーネル間の互いの関係とを含むものである。
関係マネージャは、常に、環境内で動作する複数のカーネル間の関係を管理する。各カーネルによって、多くの所定のスレッドがそれらのカーネルコードを実行する役割を果たすことができるが、この要素は、関係マネージャによって実行されるタスクには関係ない。本発明の実施の形態に基づく関係マネージャによって実行されるタスクは、カーネルと、カーネル間の互いの関係とを含むものである。
各関係マネージャは、構成の種類に応じて、ある確立されたプロトコルを用いて通信を行い、リングオニオンカーネルシステム(Ring-Onion Kernel System)内で又は4つの構成アーキテクチャのそれぞれ内のオペレーティングシステムに亘って組織化されたカーネル間で情報を共有する。図13は、リソースマネージャ921と、リソース割当マネージャ922とを示している。図13において、リソース共有(Resource Sharing)と呼ばれるプロトコル{Al}は、環境内に常駐するあるリソースの知識(knowledge)を要求する関係マネージャから送信するデータのプロトコルを表している。この図13の同じリソースマネージャ921の下の{Bl}は、全く同じプロトコルの他の層を表しており、解放されたリソース又はリソースが解放されるまでの見積時間に関する情報を通知する。第3のパラメータ及びプロトコル層である{Cl}は、要求されたリソース、解放されたリソース、又はあるリソースがどこに常駐するかに関する、受信する情報を表している。
他の具体例では、関係マネージャRM1は、関係マネージャRM2の下のリソースAlに関する要求を生成する。関係マネージャRM2が、リソースAlが使用中であることを知っている場合、関係マネージャRM2は、そのリソースマネージャRsMgr2の要求を生成し、したがって、階層プロトコル(layered protocols)のシステムを介して、要求の元に情報を送り返すことによって、リソースA1が解放されるまでの時間を見積もることができる。
関係マネージャRM1は、一旦リソースA1が解放されたことを知ると、例えば特定のプロトコル層を用いて、関係マネージャRM3に知らせる。関係マネージャRM3は、そのカーネル又はそのカーネルのスレッドの1つがリソースA1を獲得したことを知ると直ちに、リングアーキテクチャ(ring architecture)の下では、環境内の動作している全てのカーネル又はオペレーティングシステムのリソース割当マネージャに、スター−中央アーキテクチャ(Star-Center architecture)の下では、コマンド制御オペレーティングシステム又はカーネルのみに知らせる。
タスク分散のための構成(Configurations For Task Distribution)
全てのカーネルに常駐するスケジューラは、タスクをどのように分散させて実行するかを決定する中心的役割を果たすが、これらのスケジューラは、本発明にとっても重要であり、動作をどのような流れで実行するかを決定する中心的役割を果たす。本発明の実施の形態では、環境に割り当てられたタスクを実行する4種類以上の構成があり、これらの構成は、環境の中央コマンド構造であると考えられ、以下のように命名される。
全てのカーネルに常駐するスケジューラは、タスクをどのように分散させて実行するかを決定する中心的役割を果たすが、これらのスケジューラは、本発明にとっても重要であり、動作をどのような流れで実行するかを決定する中心的役割を果たす。本発明の実施の形態では、環境に割り当てられたタスクを実行する4種類以上の構成があり、これらの構成は、環境の中央コマンド構造であると考えられ、以下のように命名される。
アーキテクチャ(ARCHITECTURES)
1.階層構造(Hierarchical Structure)
本発明に基づき、環境内で複数のカーネルが同時に動作する階層構造では、ホストカーネル(host kernel)は、全ての制御の中心にあり、環境によって実行する全ての入力ジョブ又はタスクを受信する。コマンドカーネル(Command kernel)は、必要とされるリソースのタスクをスクリーニングし、特定のタスクを、このタスクが完了まで実行される適切なカーネルに割り当てる。コマンドカーネルの下には、関係マネージャがあり、関係マネージャは、コマンドカーネルと、環境内で動作する後続のカーネルとの間の関係を管理する。関係マネージャは、上述した1つと同様の制御プロトコル構造(control protocol structure)によって、他のカーネルを管理する。関係マネージャは、環境内で動作する他のカーネルのそれぞれとの間のリソース要求(resource requests)及びリソース条件を、記録して、バランスさせる。この仕事(chore)を実行するために、関係マネージャは、全てのタスク及びジョブが最初にどこに割り当てられたか、及びこれらが特定のカーネルに割り当てられた理由を理解する必要がある。階層構造の下では、環境にインストールされたリソースは、特定のカーネルに割り当てられ、例えば、プリンタは、特定のカーネルに割り当てられ、ビデオ画面(video screen)は、他のカーネルに割り当てられる。特定のI/O駆動タスク(I/O driven task)を必要とするタスクは、特定のリソースを獲得する際の遅延のために、ビデオ/オーディオ駆動タスク(video/audio driven task)に割り込まない。
1.階層構造(Hierarchical Structure)
本発明に基づき、環境内で複数のカーネルが同時に動作する階層構造では、ホストカーネル(host kernel)は、全ての制御の中心にあり、環境によって実行する全ての入力ジョブ又はタスクを受信する。コマンドカーネル(Command kernel)は、必要とされるリソースのタスクをスクリーニングし、特定のタスクを、このタスクが完了まで実行される適切なカーネルに割り当てる。コマンドカーネルの下には、関係マネージャがあり、関係マネージャは、コマンドカーネルと、環境内で動作する後続のカーネルとの間の関係を管理する。関係マネージャは、上述した1つと同様の制御プロトコル構造(control protocol structure)によって、他のカーネルを管理する。関係マネージャは、環境内で動作する他のカーネルのそれぞれとの間のリソース要求(resource requests)及びリソース条件を、記録して、バランスさせる。この仕事(chore)を実行するために、関係マネージャは、全てのタスク及びジョブが最初にどこに割り当てられたか、及びこれらが特定のカーネルに割り当てられた理由を理解する必要がある。階層構造の下では、環境にインストールされたリソースは、特定のカーネルに割り当てられ、例えば、プリンタは、特定のカーネルに割り当てられ、ビデオ画面(video screen)は、他のカーネルに割り当てられる。特定のI/O駆動タスク(I/O driven task)を必要とするタスクは、特定のリソースを獲得する際の遅延のために、ビデオ/オーディオ駆動タスク(video/audio driven task)に割り込まない。
2.ラウンドロビン(Round-Robin)
ラウンドロビン構成(Round-Robin configuration)は、所定の順序でカーネルに割り当てるタスクからなる。この場合、カーネルが、タスクを実行するために必要とされるリソースを含んでいない場合、関係マネージャは、そのタスクを次のカーネルに適切に転送する役割を果たす。本発明では、ラウンドロビン構成は、多くの異なるよくある状況に適しているが、他の状況では、本発明が意図する好ましい効果(benefits)が得られないこともある。
ラウンドロビン構成(Round-Robin configuration)は、所定の順序でカーネルに割り当てるタスクからなる。この場合、カーネルが、タスクを実行するために必要とされるリソースを含んでいない場合、関係マネージャは、そのタスクを次のカーネルに適切に転送する役割を果たす。本発明では、ラウンドロビン構成は、多くの異なるよくある状況に適しているが、他の状況では、本発明が意図する好ましい効果(benefits)が得られないこともある。
ラウンドロビン構成の下では、各カーネルは、環境内で、他のカーネルに対して非同期で動作し、関係マネージャによってリンクされ、したがって、カーネルは、各カーネルのそれぞれの下の各リソースマネージャと通信を行う。ラウンドロビン構成は、制御の中心点を有していない。この構成の場合、コマンドカーネルは存在しない。各カーネルは、抽象的環状構成(abstract circular configuration)にあるとみなされ、それぞれの関係マネージャを介して、他のカーネルに接続する。
3.先入先出(First-in First-Out:FIFO)
FIFO構成の下では、各カーネルは、環境に現れる各タスクを先着順に実行する。特定のタスクがカーネルに供給され、カーネルがその所定のタスクを受け入れるために十分に解放されている場合、タスクがリソースのためにブロックされるまでは、タスクは、そのカーネルに常駐する。
FIFO構成の下では、各カーネルは、環境に現れる各タスクを先着順に実行する。特定のタスクがカーネルに供給され、カーネルがその所定のタスクを受け入れるために十分に解放されている場合、タスクがリソースのためにブロックされるまでは、タスクは、そのカーネルに常駐する。
4.スター−中央(Star-Center)
スター−中央アーキテクチャは、中央コマンドカーネル(central command kernel)を環状に取り囲む複数のカーネルを有する構成として定義される。中央コマンドカーネルは、制御カーネル(controlling kernel)であり、その機能を用いて、スター構成(Star configuration)の下の他のカーネルのためのタスク要求を受信して、組織化する。スター−中央構成(Star-Center configuration)は、環境内のリソースに基づいて、下位のカーネルを星座(constellation)にグループ化する。ここで、所定のタスクが所定のリソースを用いることを必要とし、一方、他のタスクが、多くの場合、所定のタスクが所定のリソースを用いることを完了するまで、その所定のリソースによってブロックされるオペレーティングシステムについて検討する。本発明では、カーネルスレッドは、このようなボトルネックを解消する際に、特定のカーネルをコピーするように専用とされ、これに対して、他のカーネルは、それらのスレッドを適宜用いることができる。複数のオペレーティングシステムのための多くの条件のうちの1つは、専用のカーネルが、特定の種類の複数の接続された(attached)リソースを処理するそれらのコードのコピーをスレッドアウト(thread out)する能力を用いる特定のリソースを処理することができるようにすることであり、したがって、複数のカーネルは、複数のCPU上で動作するだけではなく、複数のCPUに亘るそれら自体の複数のコピーを動作させる。
スター−中央アーキテクチャは、中央コマンドカーネル(central command kernel)を環状に取り囲む複数のカーネルを有する構成として定義される。中央コマンドカーネルは、制御カーネル(controlling kernel)であり、その機能を用いて、スター構成(Star configuration)の下の他のカーネルのためのタスク要求を受信して、組織化する。スター−中央構成(Star-Center configuration)は、環境内のリソースに基づいて、下位のカーネルを星座(constellation)にグループ化する。ここで、所定のタスクが所定のリソースを用いることを必要とし、一方、他のタスクが、多くの場合、所定のタスクが所定のリソースを用いることを完了するまで、その所定のリソースによってブロックされるオペレーティングシステムについて検討する。本発明では、カーネルスレッドは、このようなボトルネックを解消する際に、特定のカーネルをコピーするように専用とされ、これに対して、他のカーネルは、それらのスレッドを適宜用いることができる。複数のオペレーティングシステムのための多くの条件のうちの1つは、専用のカーネルが、特定の種類の複数の接続された(attached)リソースを処理するそれらのコードのコピーをスレッドアウト(thread out)する能力を用いる特定のリソースを処理することができるようにすることであり、したがって、複数のカーネルは、複数のCPU上で動作するだけではなく、複数のCPUに亘るそれら自体の複数のコピーを動作させる。
5.リングオニオンカーネルシステム(Ring-Onion Kernel System)
リングオニオンカーネルシステムでは、複数のストリップダウンカーネル(strip-down kernel)は、オペレーティングシステムのサービス構造内で同時に機能する。オペレーティングシステムのサービス構造とは、サービスの特定のオペレーティングシステムのセットを構成する全ての補助的及び予備的ファイル(ancillary and auxiliary files)を意味する。これらのサービスは、共有することができる。このアーキテクチャ、例えばシステムコール機能及びカーネルコードの外部の他の機構の下では、設計の多様性を与え、特定の必要条件下の性能に影響を与えることができる。リングオニオンカーネルシステムの場合には、カーネルの全ては、シングルオペレーティングシステムカーネルのタスクを実行するが、これらのタスクを互いに非同期で実行し、補助的なファイル及び機能を共有するときには、これらのタスクを別々のCPU上で実行する。
リングオニオンカーネルシステムでは、複数のストリップダウンカーネル(strip-down kernel)は、オペレーティングシステムのサービス構造内で同時に機能する。オペレーティングシステムのサービス構造とは、サービスの特定のオペレーティングシステムのセットを構成する全ての補助的及び予備的ファイル(ancillary and auxiliary files)を意味する。これらのサービスは、共有することができる。このアーキテクチャ、例えばシステムコール機能及びカーネルコードの外部の他の機構の下では、設計の多様性を与え、特定の必要条件下の性能に影響を与えることができる。リングオニオンカーネルシステムの場合には、カーネルの全ては、シングルオペレーティングシステムカーネルのタスクを実行するが、これらのタスクを互いに非同期で実行し、補助的なファイル及び機能を共有するときには、これらのタスクを別々のCPU上で実行する。
上述した図1は、カーネルのシステムが、同じサービス及び機能を共有するが、タスクを非同期で実行するリングオニオンカーネルシステムを示している。各カーネルは、その局所的な空間内に即時の(immediate)サービス機能のセットを有しているが、より広いサービスは、環境内の全てのカーネル間で共有される。
図1は、全てのカーネルが、コマンド及び制御カーネルなしで、互いに非同期に動作することを示しているが、本発明に基づくアーキテクチャでは、コマンド及び制御カーネルをインストールすることができ、これにより、スター−中央システムアーキテクチャと同様の仕様を、リングオニオンアーキテクチャと協調させて適用することができる。
マルチプロセッサの同期(MULTI PROCESSOR SYNCHRONIZATION)
従来の同期モデルにおいて維持されている基本的な前提条件の1つは、スレッドがカーネルから去る準備ができ、又はリソースがブロックされるまで、スレッドが、カーネルの占有権(exclusive rights)及びカーネルの使用権を維持すること(割込を除く)である。マルチプロセッサでは、各プロセッサは、カーネルコードを同時に実行することができるので、従来の同期モデルは、最早有効なモデルではなくなっている。複数のスレッドを用いるマルチプロセッサモデルの下では、各プロセッサが、カーネルコードのそのコピーを実行できるときには、全ての種類のデータを保護する必要がある。本発明の下では、1つの環境内に複数のカーネルがあり、各カーネルは、カーネルコードのそれら自体のコピーを実行する複数のプロセスによる動作の結果として、複数のスレッドを有するので、この種の保護は有効である。
従来の同期モデルにおいて維持されている基本的な前提条件の1つは、スレッドがカーネルから去る準備ができ、又はリソースがブロックされるまで、スレッドが、カーネルの占有権(exclusive rights)及びカーネルの使用権を維持すること(割込を除く)である。マルチプロセッサでは、各プロセッサは、カーネルコードを同時に実行することができるので、従来の同期モデルは、最早有効なモデルではなくなっている。複数のスレッドを用いるマルチプロセッサモデルの下では、各プロセッサが、カーネルコードのそのコピーを実行できるときには、全ての種類のデータを保護する必要がある。本発明の下では、1つの環境内に複数のカーネルがあり、各カーネルは、カーネルコードのそれら自体のコピーを実行する複数のプロセスによる動作の結果として、複数のスレッドを有するので、この種の保護は有効である。
プロセッサマネージャ(PROCESSOR MANAGER)
本発明の下では、プロセッサ、したがってCPUは、他のリソースと同様に、管理されるリソースとなる。より具体的には、プロセッサマネージャは、CPUの数と、環境の下で動作するカーネル、又はカーネルスレッドの使用を管理するカーネル固有のプロセスのコピーに対するCPUの割当とを管理するプロセスである。特別なカーネルコードのコピーを実行して、特定のリソースを利用するカーネルスレッドを使用するための各要求は、プロセッサマネージャによって管理される。プロセッサの数は、プロセッサマネージャによって、分類されて(catalogued)、現在の環境内で実行中の各スレッドに割り当てられなければならない。
本発明の下では、プロセッサ、したがってCPUは、他のリソースと同様に、管理されるリソースとなる。より具体的には、プロセッサマネージャは、CPUの数と、環境の下で動作するカーネル、又はカーネルスレッドの使用を管理するカーネル固有のプロセスのコピーに対するCPUの割当とを管理するプロセスである。特別なカーネルコードのコピーを実行して、特定のリソースを利用するカーネルスレッドを使用するための各要求は、プロセッサマネージャによって管理される。プロセッサの数は、プロセッサマネージャによって、分類されて(catalogued)、現在の環境内で実行中の各スレッドに割り当てられなければならない。
一具体例では、複数のプロセスが通信するためのプロセス間通信テーブル、特に最新のカーネル内に存在するプロセス間通信テーブルに対するアクセスを提供する。プロセス間通信テーブルのデータ構造は、割込ハンドラ(interrupt handler)によってはアクセスされず、データ構造にアクセスするプロセスをブロックする可能性がある如何なる動作もサポートしていない。したがって、ユニプロセッサシステム(uniprocessor system)では、カーネルは、テーブルをロックすることなく、テーブルを操作することができる。しかしながら、マルチプロセッサシステム(multiprocessor system)の下では、こういうことは、行うことができない。したがって、本発明の下では、このようなテーブルは、常駐するカーネルコードの複数のコピーを実行する複数のプロセスが協調し(cooperation)、及び他のカーネルに接続された(attached)複数のリソースを使用することが必要な複数のカーネルが協調するように、拡張しなければならない。本発明では、2つのプロセスが、プロセス間で同時に通信するために、このようなテーブルに一旦アクセスすると、このようなテーブルをロックしなければならず、プロセッサマネージャがこのようなテーブルの管理を実行できるように、現在の抽象化(abstract)を変更することを提案する。2つ以上のプロセスが同時にIPCテーブルにアクセスすることを試みたとき、プロセッサマネージャは、1つ以上のプロセスがそれらの通信リンクを終了するまで、且つ他のプロセスがIPCテーブルにアクセスすることが許可されるようになる前に、IPCテーブルをロックしなければならない。ロック機構(locking mechanism)は、IPC通信の基本であり、本発明の下では、ロック機構は、3つ以上のプロセスが同時に通信できるようにするために、マルチプロセッサシステムのIPC通信に対応するように拡張することができる。
プロセス間通信テーブル(Inter-process Communication Table)
カーネル間通信テーブル(INTER-KERNEL COMMUNICATION TABLE)
従来のカーネルシステムの下では、カーネルは、単にロックフラグを調べ、カーネル間通信テーブルをロックするために、ロックフラグをロック位置に設定し、あるいは、カーネル間通信テーブルをアンロックするために、ロックフラグをリセットするようになっている。本発明の下では、プロセス間通信(IPC)及びカーネル間通信(IKT)は、それらに応じて管理されるシステム内のもう1つのリソースになる。これらのテーブルの複雑性(complexity)によって、システム環境の洗練度(sophistication)のレベルが決まる。本発明の下では、マルチプロセッサシステムの場合に、異なるプロセッサ上で動作するが、1つのプロセッサマネージャによって管理される2つのスレッドは、同じリソースに対する単一のロックフラグを同時に調べることができる。両方のスレッドは、ロックフラグが解除されたことが分かると、同時に特定のリソースにアクセスすることを試みる。したがって、本発明では、1つのプロセスだけがロックフラグの検査を実行し、この場合、このような検査は、リソースがプロセッサである場合には、プロセッサマネージャによって行われ、リソースがプロセッサ以外のものである場合には、リソースマネージャによって行われる。このようなマネージャの分割によって、同時のアクセスが予測できない結果となることを、ある程度防止することができる。
カーネル間通信テーブル(INTER-KERNEL COMMUNICATION TABLE)
従来のカーネルシステムの下では、カーネルは、単にロックフラグを調べ、カーネル間通信テーブルをロックするために、ロックフラグをロック位置に設定し、あるいは、カーネル間通信テーブルをアンロックするために、ロックフラグをリセットするようになっている。本発明の下では、プロセス間通信(IPC)及びカーネル間通信(IKT)は、それらに応じて管理されるシステム内のもう1つのリソースになる。これらのテーブルの複雑性(complexity)によって、システム環境の洗練度(sophistication)のレベルが決まる。本発明の下では、マルチプロセッサシステムの場合に、異なるプロセッサ上で動作するが、1つのプロセッサマネージャによって管理される2つのスレッドは、同じリソースに対する単一のロックフラグを同時に調べることができる。両方のスレッドは、ロックフラグが解除されたことが分かると、同時に特定のリソースにアクセスすることを試みる。したがって、本発明では、1つのプロセスだけがロックフラグの検査を実行し、この場合、このような検査は、リソースがプロセッサである場合には、プロセッサマネージャによって行われ、リソースがプロセッサ以外のものである場合には、リソースマネージャによって行われる。このようなマネージャの分割によって、同時のアクセスが予測できない結果となることを、ある程度防止することができる。
スレッドマネージャ(THREAD MANAGER)
本発明では、スレッドマネージャは、現在のローカルカーネル(local kernel)の下で動作するプロセスとして定義され、現在のローカルカーネルの下で動作する軽量プロセス(lightweight process:LWP)及び他のプロセスに割り当てられた全てのスレッドの使用を追跡する。スレッドマネージャは、この情報を、複数のカーネル環境(Multiple Kernel Environment:MKE)の同期を支援するように動作する他の管理システムに報告する。MKEが上述した5つの構成のうちの1つに組織化された場合、スレッドマネージャの報告は、この特定の環境の必要条件を満たすように変更することができる。スレッドマネージャにとって、重要なことは、例えば、特定のシステムの下で、所定のリソースをより正確に追跡するために、割り当てられたスレッドの数を報告することである。リソースの報告は、リソースマネージャの役割であり、したがって、リソースマネージャは、この種類の情報を提供するスレッドマネージャに依存する。
本発明では、スレッドマネージャは、現在のローカルカーネル(local kernel)の下で動作するプロセスとして定義され、現在のローカルカーネルの下で動作する軽量プロセス(lightweight process:LWP)及び他のプロセスに割り当てられた全てのスレッドの使用を追跡する。スレッドマネージャは、この情報を、複数のカーネル環境(Multiple Kernel Environment:MKE)の同期を支援するように動作する他の管理システムに報告する。MKEが上述した5つの構成のうちの1つに組織化された場合、スレッドマネージャの報告は、この特定の環境の必要条件を満たすように変更することができる。スレッドマネージャにとって、重要なことは、例えば、特定のシステムの下で、所定のリソースをより正確に追跡するために、割り当てられたスレッドの数を報告することである。リソースの報告は、リソースマネージャの役割であり、したがって、リソースマネージャは、この種類の情報を提供するスレッドマネージャに依存する。
リソースマネージャ(RESOURCE MANAGER)
本発明では、リソースマネージャは、環境内に存在すると考えられるリソースのマネージャとして定義される。例えば、リソースは、あらゆるオペレーティングシステム環境に不可欠なコンポーネントであると考えられ、したがって、複数のカーネルが常駐する又は常駐できるシステムの下では、このステートメント(statement)は、重要な意味を持つ。リソースマネージャは、ローカルカーネルレベルに常駐するリソースを管理し、あるタスクが特定のリソースを要求する毎に、これらの要求は、リソースマネージャを介して行われ、特定のカーネル上では利用不可能なリソースに対する要求が行われた場合、リソースマネージャは、リソースを必要とするタスクと、特定のリソースを有するカーネルとの間に関係を築くために、関係マネージャに連絡する。
本発明では、リソースマネージャは、環境内に存在すると考えられるリソースのマネージャとして定義される。例えば、リソースは、あらゆるオペレーティングシステム環境に不可欠なコンポーネントであると考えられ、したがって、複数のカーネルが常駐する又は常駐できるシステムの下では、このステートメント(statement)は、重要な意味を持つ。リソースマネージャは、ローカルカーネルレベルに常駐するリソースを管理し、あるタスクが特定のリソースを要求する毎に、これらの要求は、リソースマネージャを介して行われ、特定のカーネル上では利用不可能なリソースに対する要求が行われた場合、リソースマネージャは、リソースを必要とするタスクと、特定のリソースを有するカーネルとの間に関係を築くために、関係マネージャに連絡する。
リソース割当マネージャ(RESOURCE ALLOCATION MANAGER)
本発明では、リソース割当マネージャは、特定のリソースを用いて1つのカーネル上で開始するが、他のカーネルに接続(attached)される可能性があるリソースを必要とする開始タスクを有するプロセス間に割り当てられた全てのリソースの記録を行う。このような状況では、リソースマネージャは、特定のリソースを見つけ、あるいは環境内の利用可能な全てのリソースの目録を作る(inventory)ためには、リソース割当マネージャと連絡する必要がある。このような場合、カーネル間の全てのリソース割当を管理するリソース割当マネージャは、必要な情報をリソースマネージャに供給する。
本発明では、リソース割当マネージャは、特定のリソースを用いて1つのカーネル上で開始するが、他のカーネルに接続(attached)される可能性があるリソースを必要とする開始タスクを有するプロセス間に割り当てられた全てのリソースの記録を行う。このような状況では、リソースマネージャは、特定のリソースを見つけ、あるいは環境内の利用可能な全てのリソースの目録を作る(inventory)ためには、リソース割当マネージャと連絡する必要がある。このような場合、カーネル間の全てのリソース割当を管理するリソース割当マネージャは、必要な情報をリソースマネージャに供給する。
あるアーキテクチャの下では、リソース割当マネージャ及びリソースマネージャは、コマンドカーネルシステム又は環境内のオペレーティングシステム以外の、OS又はカーネルシステム内に存在することができる。本発明の実施の形態を説明するために、リソース割当マネージャ及びリソースマネージャの両方は、コマンドオペレーティング及びカーネルシステム(Command Operating and Kernel System)の一部として存在しているものとする。
更なる具体例
図14〜図23は、本発明の実施の形態のより詳細な具体例を示している。本発明の一実施の形態では、KOSは、中央ではなく、個々のオペレーティングシステム内で実行される。プロセスは、情報を、例えば共有メモリを用いて交換して、何時リソースが利用可能か、又は何時リソースが利用可能になるかを他のプロセスに通知する。一具体例として、図14は、リソースR1に関する情報を、共有メモリ1015を用いて交換する2つのプロセス1001、1010を示している。共有メモリ1015は、プロセス1010が待っているリソースR1が、今利用可能になったことを示す情報を含んでいる。このとき、プロセス1010は、リソースR1を、例えばリソースR1に対するコールを生成することによって要求することができる。
図14〜図23は、本発明の実施の形態のより詳細な具体例を示している。本発明の一実施の形態では、KOSは、中央ではなく、個々のオペレーティングシステム内で実行される。プロセスは、情報を、例えば共有メモリを用いて交換して、何時リソースが利用可能か、又は何時リソースが利用可能になるかを他のプロセスに通知する。一具体例として、図14は、リソースR1に関する情報を、共有メモリ1015を用いて交換する2つのプロセス1001、1010を示している。共有メモリ1015は、プロセス1010が待っているリソースR1が、今利用可能になったことを示す情報を含んでいる。このとき、プロセス1010は、リソースR1を、例えばリソースR1に対するコールを生成することによって要求することができる。
なお、図14では、単一のリソースに関する情報を含む共有メモリを示したが、他の実施の形態では、共有メモリは、多くのリソースに関する情報を含んでいる。また、共有メモリは、図14に示す情報とは異なる情報、又はこれに加えて更なる情報を含むことができる。
他の実施の形態においては、各KOSは、他のKOS及びそれらがサポートしているリソースを示すテーブルを含んでいる。また、このテーブルは、リソースがどのように呼び出されるか(例えば、オペレーティングシステムに対するエントリポイント又はシステムコールによって)と、現在、特定のオペレーティングシステムを実行しているプロセッサの負荷とを示す。例えば、図15A〜図15Cは、3つのプロセッサが存在し、各プロセッサが、KOSを実行するとともに、異なるリソースをサポートする環境において、各KOS内のテーブルの具体例を示している。図15Aは、オペレーティングシステムOS1に記憶されているテーブルを示している。図15Aの行1101は、オペレーティングシステムOS2がエントリポイントP2を有し、リソースR2、R3をサポートし、システム(プロセッサ)の負荷が10%であることを示している。行1103は、オペレーティングシステムOS3がエントリポイントP3を有し、リソースR3をサポートし、システムの負荷が40%であることを示している。
オペレーティングシステムOS2に記憶されている図15Bのテーブル及びオペレーティングシステムOS3に記憶されている図15Cのテーブルは、同じように説明されるので、ここでは説明しない。動作において、オペレーティングシステムは、互いに情報を、周期的に、例えば特定の時間毎に、あるいは所定の閾値を超えてそのリソースパラメータが変化したときに交換する。
図16は、リソース情報を異なるフォーマットで格納し、リソースをオペレーティングシステムにマッピングするテーブル1200を示している。例えば、図16のテーブル1200の行1201は、現在、リソースR1がオペレーティングシステムOS1を介してアクセス可能であることを示しており、行1202は、リソースR2がオペレーティングシステムOS2、OS1を介してアクセス可能であることを示しており、行1203は、リソースR3がオペレーティングシステムOS2、OS3を介してアクセス可能であることを示している。
図15A〜図15C及び図16のテーブルは、単に例示的に示しているだけである。当業者は、本発明の実施の形態に基づき、リソーステーブルに含まれる多くの異なるフォーマット及び種類の情報を想到することができる。
図17は、本発明の一実施の形態に基づき、複数のKOSがリソース情報を交換するシステム1250を示している。システム1250は、関係マネージャ1251A及びリソースマネージャ1251Bを有するKOS1251と、関係マネージャ1255A及びリソースマネージャ1255Bを有するKOS1255と、関係マネージャ1260A及びリソースマネージャ1260Bを有するKOS1260とを備える。上述したように、KOSがリソースを必要としたとき、KOSは、そのローカルのカーネルレベルを、リソースマネージャを用いて調べる。リソースを見つけることができない又はリソースが利用不可能な場合、KOSは、その関係マネージャを呼び出して、他のKOSを介してリソースにアクセスする。
図18〜図23は、本発明に基づく中央のKOS(central KOS)の実施の形態を示している。図18は、それぞれが1つ以上のリソースにアクセスするように構成された複数のオペレーティングシステムOS1(1310)、OS2(1311)、OS3(1312)、OS4(1313)を実行するコンピュータシステム1300を示している。オペレーティングシステムOS1(1310)、OS2(1311)の両方は、プリンタ1320にアクセスするように構成されている。オペレーティングシステムOS3(1312)は、ディスク1321にアクセスするように構成されており、オペレーティングシステムOS4(1313)は、ビデオディスプレイ1322にアクセスするように構成されている。一実施の形態においては、オペレーティングシステムOS4(1313)は、特に、ビデオディスプレイ1322とインタフェースするように適応化されている。すなわち、例えば、オペレーティングシステムOS4(1313)は、ビデオディスプレイドライバを備え、オペレーティングシステムOS1(1310)、OS2(1311)、OS3(1312)は、ビデオディスプレイドライバを備えていない、あるいは、ビデオディスプレイ1322に対するオペレーティングシステムOS4(1313)のインタフェースは、より多くの特徴、例えばメモリ使用量が少ない、より速い等、又はこれらを組み合わせた特徴をサポートしている。システム1300上の一部のオペレーティングシステムだけが所定のリソースにアクセスするように構成され、他のオペレーティングシステムがこのように構成されていない、あるいは、幾つかのオペレーティングシステムが、他のオペレーティングシステムに比して、特定のリソースにアクセスするのに適しているという多くの理由は、当業者にとって明らかである。
動作において、プロセスは、リソースを使うことを要求し、カーネル動作スケジューラ(kernel operational scheduler:KOS)1305に導入される。KOS1305は、まず、オペレーティングシステムOS1(1310)〜OS4(1313)のうちのどれが、要求されたリソースをプロセスに供給するに最適であるかを決定し、次に、選択したオペレーティングシステムにプロセスを割り当てる。複数のオペレーティングシステムが要求されたリソースを供給することができるときは、KOS1305は、後述する選択基準を用いる。一具体例として、プロセスは、プリンタ1320にアクセスするために、プリント機能を呼び出す。オペレーティングシステムOS1(1310)、OS2(1311)の両方がプリンタ1320にアクセスすることができるが、オペレーティングシステムOS1(1310)の方がビジーでないので、オペレーティングシステムOS1(1310)が選択される。
図19は、KOS1305を更に詳細に示している。図19に示すように、一実施の形態では、KOS1305は、コマンドカーネル1400と、関係マネージャ1410とを備える。
図20は、本発明の一実施の形態に基づき、図19の関係マネージャ1410に記憶されているプロセステーブル(process table)1450を示す。プロセステーブル1450は、プロセスと、プロセスに割り当てられるリソースと、それらの優先度とに関する情報を格納している。例えば、テーブル1450の行1451は、プロセスID1572を有するプロセスは、現在、リソースR1が割り当てられているとともに、1位の優先度を有することを示している。
なお、プロセステーブル1450には、他の情報、例えば、幾つかの他の種類の情報を上げると、プロセスがリソースを待っているか、プロセスがどれくらい長くリソースを待っているかを示す情報を格納することができることは、明らかである。
図21は、本発明の一実施の形態に基づいて、プロセスを処理するカーネルオペレーティングシステムをスケジューリングする方法1500のフローチャートである。開始ステップ1501に続くステップ1503において、処理は、コンピュータシステム上で実行されているオペレーティングシステム(OS)のうちのどれがリソースを供給することができるかを判定する。次に、ステップ1505において、処理は、2つ以上のOSがリソースを供給することができるかを判定する。OSのうちの1つだけがリソースを供給することができる場合、処理は、ステップ1515にスキップし、該当する場合、処理は、ステップ1510に進む。
ステップ1510において、処理は、図22に関連して後述するように、1つ以上の選択基準を用いて、複数のOSのうちの1つを選択し、ステップ1515に進む。ステップ1515において、処理は、リソースをプロセスに割り当て、ステップ1520において、終了する。
図22は、要求された全てのリソースを供給することができる複数のカーネルオペレーティングシステムの中から1つのカーネルオペレーティングシステムを選択する、図21に示すステップ1510の詳細を示している。最初のステップ1550において、処理は、負荷が最小のオペレーティングシステムを選択する。ステップ1555において、処理は、1つのOSがこの基準を満たすかを判定する。該当する場合、処理は、ステップ1575にスキップする。該当しない場合、処理は、ステップ1560に進み、最少の負荷を有するOSのみを検討から外す。
ステップ1560において、処理は、残りのOSから、実行待ちプロセス又はブロックプロセスが最も少ないOSのみを選択して、残りを検討から外す。ステップ1565において、処理は、実行待ちプロセス又はブロックプロセスが最も少ないOSが1つだけかを判定する。実行待ちプロセス又はブロックプロセスが最も少ないOSが1つだけの場合、処理は、ステップ1575にスキップする。該当しない場合、処理は、ステップ1570に進み、ここにおいて、残りのOSから、回転、すなわち他のラウンドロビン方式によって1つのOSを選択する。次に、ステップ1575において、処理は、選択されたOSを介して、要求されたリソースをプロセスに割り当てる。この処理は、ステップ1580において終了する。ここで、「選択基準」は、OSの状態(実行待ちプロセス又はブロックプロセスの数、及びOSを実行しているプロセッサの負荷)を含んでいると言える。
なお、ステップ1510は、単に例示的に示しているだけである。当業者は、多くの変形例を想到することができる。例えば、ステップ1510のステップは、異なる順序に並べ替えてもよく、幾つかのステップを追加してもよく、幾つかのステップを削除してもよく、あるいは、全く異なるステップの組を実行してもよい。異なるステップの1つとして、2つのOSの両方がリソースを供給することができる場合、より高速のマイクロプロセッサ上で実行されているOSを選択する。
図23は、本発明の一実施の形態に基づくシステム1600のコンポーネントと、プロセスがコンピュータシステム上のリソースを要求したときのトランザクションのシーケンスとを示している。システム1600は、プロセス1610Aを実行して、リソース1610Bに対するアクセスを供給するオペレーティングシステム1610と、プロセス1660Aを実行して、リソース1660B〜1660Dに対するアクセスを供給するオペレーティングシステム1660と、KOS1650とを備える。
図23に示すように、プロセス1610Aは、リソース1660Bに対する、例えばリソースマネージャを介した要求1706を生成する。破線1706で示すように、リソース1660Bは、ローカルでは入手できないので、リソース1660Bに対する要求1720がKOS1650に送られる。KOS1650は、OS1660がリソースを供給することができると判定し、リソース1660Bに対する要求1730をOS1660に送り、OS1660は、リソース1660Bを供給する。
リソースを供給する処理は、要求された特定のリソースによって異なる。リソースがCPUである場合、割当は、プロセスの識別子を、OS1660内の実行待ちキュー(run queue)に設定することを含むことができる。リソースがディスクである場合、割当は、プロセスをディスクにディスパッチするキューに、プロセスを置くことを含むことができる。
本発明では、プロセスを、1つのOSから他のOSに渡す(handed-off)ことができる。一具体例として、プロセスが、1つのOSを介してリソースにアクセスしているときに、そのOSを実行しているプロセッサに他のタスクが割り当てられた場合には、プロセスは遅くなる。換言すれば、OSもリソースである。本発明に基づくKOSは、プロセスを、より効率的に実行できる他のCPUに再び割り当てることができる。
本発明の実施の形態では、リソースを効率的に共有することができ、リソースを供給するオペレーティングシステム間で負荷をバランスさせることができる。これにより、ボトルネック、プロセス飢餓及びマルチプロセッサシステムに悪影響を与える他の徴候を低減することができる。更に、リソース及び特定のタスクを実行するように特化されたオペレーティングシステムを、プロセスに容易に割り当てることができ、これにより、プロセスを効率的に実行することができる。
なお、ここに説明した本発明に基づくKOS、その各コンポーネント、各アルゴリズムは、KOSの機能を実現するためにコンピュータにより実行可能な命令として、コンピュータにより読取可能な媒体に、記録することができる。これらの命令は、1つ以上のソフトウェアコンポーネントとしてコンピュータにより読取可能な媒体に記録してもよく、1つ以上のハードウェアコンポーネントであってもよく、これらの組合せであってもよく、コンピュータによって使用され、アルゴリズムのステップを実行する如何なる要素であってもよい。
本発明の原理及び動作の理解を容易にするために、本発明の特定の実施の形態を詳細事項を用いて説明してきたが、ここで参照した特定の実施の形態及びその詳細事項は、本発明の請求の範囲を限定するものではない。本発明の趣旨及び範囲から逸脱することなく、上に例示した実施の形態を変更できることは、当業者にとって明らかである。
Claims (9)
- 1つのカーネルスケジューラと、カーネル間通信テーブルへのアクセスのロックまたは許可を示すフラグを用いてアクセスされるカーネル間通信テーブルと、
複数のリソースにアクセスする複数のオペレーティングシステムカーネルと、
カーネルに割り当てる複数のプロセッサを管理するプロセッサー マネージャーと、
ローカルカーネルレベルに常駐するリソースに対する要求を扱うリソースマネージャとを記憶したメモリを備え、
上記カーネルスケジューラは、上記複数のリソースのうちの1つのリソースを要求するプロセスを、上記複数のオペレーティングシステムカーネルのうちの1つに割り当て、
複数のオペレーティングシステムのカーネルは、割り当てリソースを調整するために上記カーネル間通信テーブルを介して互いに通信し、
要求されるリソースがプロセッサである場合には、上記プロセッサマネージャーが上記カーネル間通信テーブルへのアクセスを決定するために上記フラグを調べ、要求されるリソースがプロセッサでない場合には、上記リソースマネージャーが上記カーネル間通信テーブルのアクセスを決定するために上記フラグを調べることを特徴とするコンピュータシステム。 - それぞれが上記複数のオペレーティングシステムカーネルのうちの対応する1つを実行する複数のプロセッサを更に備える請求項1記載のコンピュータシステム。
- 上記カーネルスケジューラは、上記複数のオペレーティングシステムカーネル上のプロセスを、上記複数のプロセッサの負荷に基づいてスケジューリングすることを特徴とする請求項2記載のコンピュータシステム。
- 上記複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の2つ以上を含むことを特徴とする請求項1記載のコンピュータシステム。
- リソースの要求を、上記複数のオペレーティングシステムカーネルのうちの1つ以上に照合するプロセステーブルを更に備える請求項1記載のコンピュータシステム。
- 上記複数のオペレーティングシステムカーネルのうちのペア間の通信チャンネルを更に備える請求項1記載のコンピュータシステム。
- 上記複数のオペレーティングシステムカーネルは、プロセッサの負荷と、リソースの利用可能性と、リソースが利用可能になるまでの見積時間とに関する情報を交換することを特徴とする請求項1記載のコンピュータシステム。
- それぞれがオペレーティングシステムカーネルを実行し、1つ以上のリソースにアクセスする複数のプロセッサと、
カーネル間通信テーブルへのアクセスのロックまたは許可を示すフラグを用いてアクセスされ、オペレーティングシステムカーネル間の通信を許可するカーネル間通信テーブルと、
リソースにアクセスするために接続された複数のオペレーティングシステムカーネルのうちの1つに、リソースを要求するプロセスを照合し、該プロセスをディスパッチするようにプログラムされた割当モジュールとを備え、
要求されるリソースがプロセッサである場合には、上記カーネル間通信テーブルへのアクセスを決定するために上記フラグが第1のプロセスで調べられ、要求されるリソースがプロセッサでない場合には、上記カーネル間通信テーブルへのアクセスを決定するために第2のプロセスで調べられることを特徴とするカーネルスケジューリングシステム。 - 上記複数のプロセッサのそれぞれは、対応するプロセッサスケジューラによって制御されることを特徴とする請求項8記載のカーネルスケジューリングシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014204814A JP5891284B2 (ja) | 2014-10-03 | 2014-10-03 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014204814A JP5891284B2 (ja) | 2014-10-03 | 2014-10-03 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008285653A Division JP5676845B2 (ja) | 2008-11-06 | 2008-11-06 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015038757A JP2015038757A (ja) | 2015-02-26 |
JP5891284B2 true JP5891284B2 (ja) | 2016-03-22 |
Family
ID=52631761
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014204814A Expired - Fee Related JP5891284B2 (ja) | 2014-10-03 | 2014-10-03 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5891284B2 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9965727B2 (en) | 2016-01-14 | 2018-05-08 | International Business Machines Corporation | Method and apparatus for resolving contention in a computer system |
US9858107B2 (en) | 2016-01-14 | 2018-01-02 | International Business Machines Corporation | Method and apparatus for resolving contention at the hypervisor level |
KR20220046221A (ko) * | 2020-10-07 | 2022-04-14 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 메모리 시스템의 동작 방법 |
WO2024050804A1 (en) * | 2022-09-09 | 2024-03-14 | Qualcomm Incorporated | Dynamically varying time slice periods in a computer processor unit |
CN115915457B (zh) * | 2023-01-30 | 2023-05-23 | 阿里巴巴(中国)有限公司 | 资源调度方法、车辆控制方法、设备及系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11249916A (ja) * | 1998-03-03 | 1999-09-17 | Fujitsu Ltd | メモリ管理装置および記録媒体 |
JP4402797B2 (ja) * | 2000-03-02 | 2010-01-20 | 株式会社日立製作所 | 情報処理装置 |
JP2008097356A (ja) * | 2006-10-12 | 2008-04-24 | Canon Inc | デジタル複合機及びその制御方法、プログラム並びに記憶媒体 |
JP2008262419A (ja) * | 2007-04-12 | 2008-10-30 | Toyota Motor Corp | 情報処理装置、オペレーティングシステム選択方法、プログラム。 |
-
2014
- 2014-10-03 JP JP2014204814A patent/JP5891284B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2015038757A (ja) | 2015-02-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2704269C (en) | Uniform synchronization between multiple kernels running on single computer systems | |
JP5324934B2 (ja) | 情報処理装置および情報処理方法 | |
JP6381956B2 (ja) | 動的仮想マシンサイジング | |
KR101258502B1 (ko) | 멀티코어 아키텍처 내의 리소스 관리 | |
JP5891284B2 (ja) | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 | |
JP3678414B2 (ja) | 多重プロセッサ・システム | |
US8572626B2 (en) | Symmetric multi-processor system | |
US20060130062A1 (en) | Scheduling threads in a multi-threaded computer | |
US9417920B2 (en) | Method and apparatus for dynamic resource partition in simultaneous multi-thread microprocessor | |
JP2013506179A (ja) | 命令スレッドを組み合わせた実行の管理システムおよび管理方法 | |
JP5676845B2 (ja) | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 | |
Cheng et al. | vScale: Automatic and efficient processor scaling for SMP virtual machines | |
US7103631B1 (en) | Symmetric multi-processor system | |
WO2016159765A1 (en) | Many-core processor architecture and many-core operating system | |
Puthoor et al. | Oversubscribed command queues in GPUs | |
JP2008186136A (ja) | 計算機システム | |
US8539491B1 (en) | Thread scheduling in chip multithreading processors | |
Li et al. | Rosgm: A real-time gpu management framework with plug-in policies for ros 2 | |
Sodan | Loosely coordinated coscheduling in the context of other approaches for dynamic job scheduling: a survey | |
Nemati et al. | Multiprocessor synchronization and hierarchical scheduling | |
JP2015141584A (ja) | 情報処理装置、情報処理方法およびプログラム | |
Parikh et al. | Performance parameters of RTOSs; comparison of open source RTOSs and benchmarking techniques | |
Walters et al. | Enabling interactive jobs in virtualized data centers | |
CA2316643C (en) | Fair assignment of processing resources to queued requests | |
Wang et al. | Amcilk: A framework for multiprogrammed parallel workloads |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20151216 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160126 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160222 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5891284 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |