(57)【要約】【課題】  プログラミングのほか、エラーの確認および訂正を容易にする方法が求められる。【解決手段】  スレッドの実行方法が開示される。本方法は、スレッドがプリエンプト化可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示すステップを含む。【選択図】      図１
2004288162.tif 000002
【特許請求の範囲】
【請求項１】
スレッドの実行方法であって、
該方法は第１スレッドが前記スレッドをプリエンプトすることを阻止するステップを有し
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッド群を有し、
前記スレッドがオペレーティングシステムにシステムコールを行うまで、前記第１スレッドは前記スレッドをプリエンプトすることを阻止される方法。
【請求項２】
前記スレッドがプリエンプト不可能であることを示すステップをさらに有する、請求項１に記載の方法。
【請求項３】
前記スレッドがプリエンプト可能であることを示すステップをさらに有する、請求項２に記載の方法。
【請求項４】
前記スレッドがプリエンプト可能な場合に、前記第１スレッドが前記スレッドをプリエンプトすることを許可するステップをさらに有する、請求項３に記載の方法。
【請求項５】
前記オペレーティングシステムは第１スレッドが前記スレッドをプリエンプトすることを阻止する、請求項１に記載の方法。
【請求項６】
前記阻止するステップは、前記スレッドから前記第１スレッドへのコンテキスト切替を阻止するステップを含む、請求項５に記載の方法。
【請求項７】
前記オペレーティングシステムは対称マルチプロセシングコンピュータシステムを動作させるように構成されている、請求項１に記載の方法。
【請求項８】
スレッドが実行されるオペレーティングシステムであって、
該オペレーティングシステムはスレッド群を有するタスクを有し、
前記オペレーティングシステムは前記スレッドを実行させるように構成されており、
前記スレッドは前記スレッド群に属し、
前記オペレーティングシステムは、前記スレッドがプリエンプト可能またはプリエンプト不可能のいずれであるかを選択するように構成可能であるオペレーティングシステム。
【請求項９】
前記オペレーティングシステムは、前記スレッドがプリエンプト不可能な場合に、第１スレッドが前記スレッドをプリエンプトすることを阻止するようにさらに構成されており、
前記第１スレッドは前記スレッド群に属する、請求項８に記載のオペレーティングシステム。
【請求項１０】
前記オペレーティングシステムは、前記スレッドから前記第１スレッドへのコンテキスト切替を阻止するように構成されていることによって、前記第１スレッドが前記スレッドをプリエンプトすることを阻止するようにさらに構成されている、請求項９に記載のオペレーティングシステム。
【請求項１１】
前記オペレーティングシステムは、前記スレッドが前記オペレーティングシステムにシステムコールを行うまで、前記第１スレッドが前記スレッドをプリエンプトすることを阻止するように構成されていることによって、前記コンテキスト切替を阻止するようにさらに構成されている、請求項１０に記載のオペレーティングシステム。
【請求項１２】
前記オペレーティングシステムは、前記スレッドがプリエンプト可能な場合に、前記第１スレッドが前記スレッドをプリエンプトすることを許可するようにさらに構成されており、
前記第１スレッドは前記スレッド群に属する、請求項８に記載のオペレーティングシステム。
【請求項１３】
スレッドの実行方法であって、
前記スレッドがプリエンプト化可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示すステップを含む方法。
【請求項１４】
前記方法は、前記スレッドがプリエンプト不可能なスレッドであると示された場合に、第１スレッドが前記スレッドをプリエンプトすることを阻止するステップを有し
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有し、
前記スレッドがオペレーティングシステムにシステムコールを行うまで、前記第１スレッドは前記スレッドをプリエンプトすることを阻止される、請求項１３に記載の方法。
【請求項１５】
前記オペレーティングシステムは第１スレッドが前記スレッドをプリエンプトすることを阻止する、請求項１４に記載の方法。
【請求項１６】
前記阻止するステップは、前記スレッドから前記第１スレッドへのコンテキスト切替を阻止するステップを含む、請求項１５に記載の方法。
【請求項１７】
前記オペレーティングシステムは対称マルチプロセシングコンピュータシステムを動作させるように構成されている、請求項１４に記載の方法。
【請求項１８】
前記方法は、前記スレッドがプリエンプト可能なスレッドであると示された場合に、第１スレッドが前記スレッドをプリエンプトすることを許可するステップをさらに有し、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有する、請求項１３に記載の方法。
【請求項１９】
前記タスクはオペレーティングシステムによってサポートされており、
前記オペレーティングシステムは対称マルチプロセシングコンピュータシステムを動作させるように構成されている、請求項１８に記載の方法。
【請求項２０】
コンピュータシステムであって、
プロセッサと、
前記プロセッサに結合されているコンピュータ可読媒体と、
前記コンピュータ可読媒体に符号化されており、スレッドを実行するためのものであって、かつ前記プロセッサに、前記スレッドがプリエンプト化可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示させるように構成されているコンピュータコードとを有するコンピュータシステム。
【請求項２１】
前記コンピュータコードは、前記プロセッサに、
前記スレッドがプリエンプト不可能なスレッドであると示された場合に、第１スレッドが前記スレッドをプリエンプトすることを阻止させるように構成されており、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有し、
前記スレッドがオペレーティングシステムにシステムコールを行うまで、前記第１ス
レッドは前記スレッドをプリエンプトすることを阻止される、請求項２０に記載のコンピュータシステム。
【請求項２２】
前記オペレーティングシステムは、第１スレッドが前記スレッドをプリエンプトすることを阻止するように構成されている、請求項２１に記載のコンピュータシステム。
【請求項２３】
前記コンピュータコードは、前記プロセッサに、前記第１スレッドが前記スレッドをプリエンプトすることを阻止させるようにさらに構成されており、該プロセッサは、
前記スレッドから前記第１スレッドへのコンテキスト切替を阻止するように構成されている、請求項２２に記載のコンピュータシステム。
【請求項２４】
前記コンピュータシステムは対称マルチプロセシングコンピュータシステムである、請求項２１に記載のコンピュータシステム。
【請求項２５】
前記コンピュータコードは、前記プロセッサに、
前記スレッドがプリエンプト可能なスレッドであると示される場合に、前記第１スレッドが前記スレッドをプリエンプトすることを許可させるようにさらに構成されており、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有する、請求項２０に記載のコンピュータシステム。
【請求項２６】
前記タスクはオペレーティングシステムによってサポートされており、
前記コンピュータシステムは対称マルチプロセシングコンピュータシステムである、請求項２５に記載のコンピュータシステム。
【請求項２７】
コンピュータプログラム物であって、
コンピュータシステムにおいて実行可能であり、かつスレッドがプリエンプト化可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示すように構成されている命令の第１の組と、
コンピュータ可読媒体とを有し、前記コンピュータ可読媒体に符号化されているコンピュータプログラム物。
【請求項２８】
前記コンピュータシステムにおいて実行可能であり、かつ前記スレッドがプリエンプト不可能なスレッドであると示された場合に、第１スレッドが前記スレッドをプリエンプトすることを阻止するように構成されている命令の第２の組を有し、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有し、
前記スレッドがオペレーティングシステムにシステムコールを行うまで、前記第１スレッドは前記スレッドをプリエンプトすることを阻止される、請求項２７に記載のコンピュータプログラム物。
【請求項２９】
前記オペレーティングシステムは、前記第１スレッドが前記スレッドをプリエンプトすることを阻止するように構成されている、請求項２８に記載のコンピュータプログラム物。
【請求項３０】
前記コンピュータシステムにおいて実行可能であり、かつ前記スレッドがプリエンプト可能なスレッドであると示される場合に、前記第１スレッドが前記スレッドをプリエンプトすることを許可するように構成されている命令の第２の組を有し、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有する、請求項２７に記載のコンピュータプログラム物。
【請求項３１】
スレッドを実行するための装置であって、
前記スレッドがプリエンプト化可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示す手段を有する装置。
【請求項３２】
前記装置は、前記スレッドがプリエンプト不可能なスレッドであると示された場合に、第１スレッドが前記スレッドをプリエンプトすることを阻止するための手段をさらに有し、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有し、
前記スレッドがオペレーティングシステムにシステムコールを行うまで、前記第１スレッドは前記スレッドをプリエンプトすることを阻止される、請求項３１に記載の装置。
【請求項３３】
前記オペレーティングシステムは第１スレッドが前記スレッドをプリエンプトすることを阻止する、請求項３２に記載の装置。
【請求項３４】
前記阻止するための手段は、前記スレッドから前記第１スレッドへのコンテキスト切替を阻止するための手段をさらに有する、請求項３３に記載の装置。
【請求項３５】
前記オペレーティングシステムは対称マルチプロセシングコンピュータシステムを動作させるように構成されている、請求項３２に記載の装置。
【請求項３６】
前記装置は、前記スレッドがプリエンプト可能なスレッドであると示された場合に、前記第１スレッドが前記スレッドをプリエンプトすることを許可するための手段をさらに有し、
前記第１スレッドおよび前記スレッドはスレッド群に属し、
タスクが前記スレッドを有する、請求項３１に記載の装置。
【請求項３７】
前記タスクはオペレーティングシステムによってサポートされており、
前記オペレーティングシステムは対称マルチプロセシングコンピュータシステムを動作させるように構成されている、請求項３６に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（添付の付録への相互参照）
付録Ａは、ＣＤ−ＲＯＭ（同ＣＤ−ＲＯＭのコピーが２部ここに添付されている）に収録されている下記のファイルを含む。付録Ａは、本開示の一部であり、参照によりその全てがここに援用される。
【０００２】
10/30/2002 1:16a 8,638 operaini.c.txt 
10/30/2002 11:14a 6,730 majcregs.h.txt
12/16/2002 04:01p 17,549 opera.c.txt
10/30/2002 11:14a 23,789 opera.h.txt
12/16/2002 04:02p 12,103 operacli.c.txt 
10/30/2002 11:15a 1,839 operacpy.txt
10/30/2002 11:15a 7,228 operaelf.c.txt
10/30/2002 11:15a 11,031 operaelf.c.txt 
10/30/2002 11:16a 1,957 operagbl.txt
10/30/2002 11:13a 29,663 majc.S.txt 
10/30/2002 11:16a 100,072 operaknl.c.txt
10/30/2002 11:16a 23,812 operaldr.c.txt 
10/30/2002 11:17a 7,109 operalib.c.txt
10/30/2002 11:17a 10,905 operamem.c.txt 
10/30/2002 11:17a 7,552 operatsk.c.txt
12/16/2002 04:09p 21,108 operatst.c.txt 
12/16/2002 04:15p 1,061 filelist.txt
付録Ａのファイルは、コンピュータプログラムのソースコードであり、本発明の例示的な実施形態を示すデータである。より詳細には、上記ファイルは、Ｃ言語およびアセンブラプログラミング言語で記述されたソースコードであり、ここに記載する諸機能を提供するオペレーティングシステムの実施形態である。
【０００３】
本発明は、オペレーティングシステムに関し、より詳細には、任意選択のスレッドプリエンプト化と共に、ユーザーモードタスクをサポートするオペレーティングシステムアーキテクチャに関する。
【背景技術】
【０００４】
オペレーティングシステムとは、コンピュータシステムのリソースを管理すると共に、コンピュータプログラムの作成を容易にし、システムでのプログラムの実行を制御するように特別に設計されているプログラムおよびデータの集合体である。オペレーティングシステムによって、コンピュータでプログラムを実行しようとする各ユーザーに、個別かつ一意的にコンピュータのハードウェアに対するアクセスを付与する必要がなくなる。これにより、プログラムとコンピュータのハードウェアとのインターフェイスを取るルーチンを記述する必要がなくなるため、ユーザーのプログラミング作業が簡単になる。ユーザーは、ルーチンを記述する代わりに、標準のシステムコールを使用することによって、上記の機能を利用できる。システムコールは総称的にアプリケーションプログラミングインターフェイス（ＡＰＩ）と呼ばれる。
【０００５】
現在、オペレーティングシステムの設計では、小規模なオペレーティングシステムが主流となっている。より詳細には、マイクロカーネルと呼ばれるオペレーティングシステムがより多く用いられるようになっている。あるマイクロカーネル型オペレーティングシス
テムのアーキテクチャにおいては、オペレーティングシステムに通常関連する一部の機能は、オペレーティングシステムのＡＰＩコールを介して利用される。これらは、ユーザー空間に移されて、ユーザータスクとして実行される。このため、マイクロカーネルは、複雑なオペレーティングシステムよりも動作が高速で、単純なことが多い。
【０００６】
上記の利点は、標準のオペレーティングシステムが提供する多様な機能を必要としない特殊用途においては特に有用である。例えば、マイクロカーネルを利用したシステムは、組み込みアプリケーションに特に適する。組み込みアプリケーションには、情報機器（個人情報端末［ＰＤＡ］、ネットワークコンピュータ、携帯電話端末などの機器）、家庭用電気製品（テレビジョン、コンピューターゲーム、調理器具等）などのアプリケーションがある。マイクロカーネルでは、モジュールを付加することによってシステムの拡張ができる（ｍｏｄｕｌａｒｉｔｙ）ため、必要な機能（モジュール）のみを利用することができる。このため、マイクロカーネルを採用して、機器の動作に必要なモジュールのみを追加することによって、上記の機器を動作させるためのコードを極力小さくすることができる。また、マイクロカーネルは簡潔であるため、機器のプログラミングが簡単になる。
【０００７】
リアルタイムアプリケーション、特に組み込みリアルタイムアプリケーションにおいては、マイクロカーネル型のオペレーティングシステムアーキテクチャの高速性が非常に有利となる。対応するカーネルコードの実行に要する時間をより正確に予測することができれば、システムコールが簡単になる。裏を返せば、これによってリアルタイムアプリケーションのプログラミングが簡単になる。これは、組み込みシステムに多く採用されているような、制御操作のソフトウェアを記述する際には特に重要である。
【０００８】
組み込みシステムでは、スレッドされた化プロセスを使用することによって、プロセスの一部（スレッド）を実行させつつ、プロセスの別の部分（スレッド）を待機させて、処理能力の使用効率を向上させていることが多い。このため、あるプロセスの一部分がイベント（Ｉ／Ｏ、システムリソースの利用など）を待機しているという理由のみによって、プロセス全体の処理を中断しなくても済む。別の例として、対称マルチプロセッサ（ＳＭＰ）アーキテクチャを採用しているコンピュータシステムにおいてスレッドされた化プロセスを使用する場合がある。この場合、マルチスレッドされた化プロセスのうちの少なくとも１つのスレッドを、複数のプロセッサに移動させて、負荷分散させることができる。スレッドの移動が動的であれば、負荷分散を動的に実行することができる。マルチスレッドのサポートは、所定のオペレーティングシステムに提供することも、ユーザーライブラリに提供することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、スレッド化アプリケーションを使用することは、リアルタイムアプリケーションのみならず、その他のアプリケーションにおいても困難であり得る。例えば、単一タスク内の複数のスレッドが、互いにプリエンプトする（すなわち、非同期的に実行して、互いに制御を奪い合う）ことがあり得る。複数のスレッドが互いにプリエンプトすることによって、タイミングに起因するエラー（すなわち非同期「バグ」）が発生することがある。通常、タイミングに起因しないエラーの検出と訂正は、比較的簡単である。これは、一部には、タイミングに起因しないエラーは容易に再現できるためである。この種のエラーを有するプログラミングコードは、入力が同じである場合、常に同じエラーを発生させる（すなわち、プログラムの状態が同じである仮定した場合、エラーを含むコードを通過するとエラーが発生する）。
【００１０】
これに対して、タイミング起因エラーは、非同期的（時間と順序に無関係）な入力（例えば、割込またはスレッドの実行順序）の状態が一因となって発生する。非同期入力およ
びスレッドの実行順序などのパラメータを制御することは不可能ではないが非常に困難であるため、この種のエラーを分離して確認することは極めて難しい。マルチスレッドされた化プロセスの複数のスレッドが独立して実行する（互いにプリエンプトできるようにする）ことが望ましい一方で、タイミング起因エラーを容易に確認および訂正できるようにすることが望まれる。
【課題を解決するための手段】
【００１１】
本発明の一実施形態においては、スレッドの実行方法が開示される。本方法は、スレッドがプリエンプト可能なスレッドまたはプリエンプト不可能なスレッドのいずれであるかを示すステップを含む。
【００１２】
本発明の別の実施形態においては、スレッドの実行方法が開示される。本方法は、第１スレッドがこのスレッドをプリエンプトすることを阻止するステップを有する。第１スレッドおよびこのスレッドは多数のスレッドに属する。タスクはこれらのスレッドを有する。このスレッドがオペレーティングシステムにシステムコールを行うまで、第１スレッドはこのスレッドをプリエンプトすることを阻止される。
【発明を実施するための最良の形態】
【００１３】
上記は、本発明の概要であって、必然的に本発明の詳細を一般化、簡略化し、省略したものである。このため、当業者は、上記の概要は例示的なものに過ぎず、いかなる方法においても限定を意図したものではないことを理解する。他の態様、発明的特徴ならびに本発明の利点は、特許請求の範囲によってのみ定義され、これらは、限定を意図したものではない下記の詳細説明を読めば明らかとなる。
【００１４】
添付の図面を参照することによって、本発明をよりよく理解できるようになると共に、その多くの目的、特徴および利点が当業者にとって自明となる。
同一の参照符号が複数の図面で使用されている場合、これらは、類似ないし同一の要素を参照している。
【００１５】
下記の説明は、本発明の実施形態を詳細に記載したものであって、本発明を限定するものではない。任意の数の変形例が、下記の記載に添付の特許請求の範囲によって定義される本発明の範囲に含まれる。
（概要）
カーネルは、好ましくはスレッドプリエンプト化をサポートしている（すなわち、ユーザーが、所定のプロセスにおいてスレッドがプリエンプト可能であるかどうかを選択できる）べきであると本発明者は考える。このような機能によって、プリエンプト不可能なスレッドを使用しているタスクがアトミックな命令（ｍｕｔｅｘロックなど）を使用しないように回避できるが、スレッドが実行を待つ遅延が増大することがある。
【００１６】
（好ましくは任意選択可能に）スレッドプリエンプト化をサポートしているシステムアーキテクチャにおいては、タスクがコンテキスト切替（すなわちプリエンプト化［非同期操作］）を許容するように構成されているときにのみ、タスク内での（所定のタスク内のあるスレッドから、同じタスク内の別のスレッドへの）コンテキスト切替が許容される。タスクが同期的に構成されている場合は、各スレッドはプリエンプト不可能であって、実行を待機する必要があるため、一度に１つのスレッドしか実行することができない。これによって、同期機構を必要とすることなくスレッドの利点が得られ、それ故システムアーキテクチャが簡単になる。システムアーキテクチャ内の少なくとも１つのタスク（または全タスク）を同期的に設定できる一方で、タスク内でプリエンプト不可能とすることを任意選択できる（すなわちタスクが同期的、非同期的であるかを構成できる）ことが好ましいと考えられる。
（任意選択のスレッドプリエンプト化をサポートするオペレーティングシステムの例）
＜システムアーキテクチャの例＞
図１に、本発明の諸実施形態による、スレッドプリエンプト化システムをサポートしている（利用している）オペレーティングシステムのシステムアーキテクチャの例を示す。このシステムアーキテクチャは、図１においてマイクロカーネル１００として示される。マイクロカーネル１００は、必要最小限のディレクティブ群（オペレーティングシステムコールとも呼ばれるオペレーティングシステム関数群）を提供している。通常、これらの関数は、全てではないとしても大半が、オペレーティングシステムに関連したものであって、このオペレーティングシステムアーキテクチャのユーザー空間に存在する。オペレーティングシステムの機能の大半がユーザー空間に存在するため、スレッドプリエンプト化を制御するための機能は、このような場合に特に重要である。このため、複数のタスク（図１にタスク１１０（１）〜１１０（Ｎ）として簡略化して示す）がマイクロカーネル１００で実行されており、そのうちの一部は、オペレーティングシステム（マイクロカーネル１００）がサポートしていない機能を提供する。これらのタスクの各々（カーネル空間またはユーザー空間の少なくともいずれか）は、少なくとも１つの実行スレッド（単にスレッドとも呼ぶ）からなる。
【００１７】
スレッドは、プログラムが通過する実行経路として概念的に捉えることができる。直列化する必要のない幾つかのほぼ独立したタスクを実行する必要があることがよくある（すなわち、これらのタスクは順番に実行する必要がなく、並列に実行することができる）。例えば、データベースサーバーが、相互に関連のない多くのクライアント要求を処理する例がある。これらのクライアント要求は、一定の順序で処理する必要がないため、独立した実行単位として扱うことができ、原則的には並列に実行することができる。このようなアプリケーションをサブタスクの並行実行の機構が採用されているシステムで処理することができれば、パフォーマンスが向上すると考えられる。
【００１８】
従来のシステムでは、複数のプロセスを使用することによって、上記のようなプログラムを実行することが多い。例えば、サーバーアプリケーションのほとんどは、クライアント要求を待機しているリスナースレッドを有する。リスナーは、要求を受け取ると、新しいプロセスをフォークして、この要求を処理する。要求の処理では、プロセスをブロックし得るＩ／Ｏ操作が行われることが多いため、単一プロセッサシステムにおいても、この手法によって、同時処理の利点が得られる。
【００１９】
１つのアプリケーションで複数のプロセスを使用することによって、不具合が生じることもある。新しいプロセスをフォークするためには、負荷の高いシステムコールが必要となるため、全てのプロセスを作成することで、大きなオーバーヘッドが生じることがある。また、別のマシンまたは別のプロセッサにプロセスをディスパッチして、プロセス間での情報の受け渡しを行い、プロセスの完了まで待機して、結果を収集するための余計な処理が必要となる。さらに、この種のシステムは、特定のリソース（ネットワーク接続など）を共有するための適切な枠組み（ｆｒａｍｅｗｏｒｋ）を有さないことが多い。同時処理によって得られる利点が、複数プロセスを作成して管理するためのコストを埋め合わせない限り、このようなモデルが必要とされることはない。
【００２０】
上記の例から、プロセスの抽象化（ｐｒｏｃｅｓｓ  ａｂｓｔｒａｃｔｉｏｎ）が不適切であり、並列処理を容易に実現することが求められていることが強調される。このため、アプリケーションの全処理の一部をなし、ほぼ独立した計算ユニットという概念は、ある程度重要である。このようなユニットは、相互の対話が比較的少なく、このため同期がさほど必要とならない。アプリケーションは、この種のユニットを少なくとも１つ有し得る。スレッドの抽象化は、このような単一の計算ユニットである。
【００２１】
このため、スレッドの抽象化を用いると、プロセスが、スレッド群とリソースの集合との２つの部分に分けられる複合的なエンティティ（ｃｏｍｐｏｕｎｄ  ｅｎｔｉｔｙ）となる。スレッドとは、プロセス内の制御点を表し、一連の命令を実行する動的オブジェクトである。リソースとは、アドレス空間、オープンファイル、ユーザーの資格証明書、クォータなどであり、プロセス内の全スレッドによって共有されることも、スレッド毎に定義されることも、この両方であることもある。さらに、各スレッドは、プログラムカウンタ、スタック、レジスタコンテキストなどのプライベートなオブジェクトを有することがある。従来のプロセスは、１つの実行スレッドのみを有する。マルチスレッド化システムは、各プロセスに対して複数の実行スレッドを許容することによって、この概念を拡張している。各々属性および名前の異なる、種類の異なるスレッドを複数定義することができる。スレッドの種類には、カーネルスレッドとユーザースレッドとがある。
【００２２】
カーネルスレッドは、ユーザープロセスに関連付ける必要がなく、必要なときにカーネルによって作成されて消去される。通常、カーネルスレッドは特定の機能を実行する役割を担う。各カーネルスレッドは、共通のカーネルコード（カーネルテキストとも呼ばれる）とグローバルデータとを共有しており、独自のカーネルスタックを有する。カーネルスレッドは独立してスケジュールングすることが可能であり、カーネルの標準の同期機構を使用する。例えば、カーネルスレッドは、非同期Ｉ／Ｏなどの機能を実行する際に有用である。このような場合、カーネルは、特別な非同期Ｉ／Ｏ機構を提供する代わりに、新しいスレッドを作成して、スレッドに各々の要求を処理させる。要求は、スレッドによって同期的に処理されるが、カーネルの残りの部分からみると非同期に処理される。また、カーネルスレッドを割込の処理に使用することもできる。
【００２３】
また、ユーザーレベルでのスレッド抽象化も可能である。これは、例えば、ユーザーライブラリを実装するか、またはオペレーティングシステムによってサポートすることで実現できる。通常、この種のユーザーライブラリは、カーネルの支援を受けずにスレッドの同期、スケジューリング、および管理を行うための種々のディレクティブを提供する。カーネルの支援なしに、スレッドのユーザーレベルコンテキストを保存して復元することができるため、ユーザーライブラリを使用してユーザースレッドを実装できる。各ユーザースレッドは、例えば、ユーザーレベルのレジスタコンテキスト等の状態情報を保存するための独自の領域であるユーザースタックを有し得る。このライブラリは、現在のスレッドのスタックおよびレジスタを保存して、新しくスケジューリングされたスレッドのスタックおよびレジスタをロードすることによって、複数のユーザースレッド間でコンテキストのスケジューリングおよび切替を行う。メモリ管理レジスタを変更できる特権を有するのはカーネルのみであるため、カーネルがプロセスを切り替える役割を担う。
【００２４】
スレッドには、利点が幾つかある。１つには、スレッドの利用は、多くのアプリケーション（例えばウィンドウシステム）をプログラミングするうえで自然な手法である。また、スレッドは、非同期操作の複雑さを、スレッドのライブラリまたはオペレーティングシステムの中に隠蔽することによって、同期プログラミング様式を提供することができる。スレッドの最大の利点は、この様式が提供するパフォーマンスを向上させることにある。本発明によると、スレッドは、極めて軽く、カーネルリソースをほとんど消費せず（あるいは全く消費せず）、オペレーティングシステムにおいて作成、消去および同期の時間がかからない。
【００２５】
一連の関連する要素もしくは類似の要素（図１のタスク１１０（１）〜１１０（Ｎ）など）の最後の要素（タスク１１０（Ｎ）など）を簡潔に示すために、「Ｎ」などの変数識別子が、図１などの幾つかの例で用いられている。このような変数識別子が繰り返し用いられているが、これは、この種の要素群の大きさの間に相関関係があることを必ずしも示すものではない。このような変数識別子を使用する場合、要素群の数が、同じ変数識別子
によって示される別の要素群の数と同じである必要はない。「Ｎ」などの変数識別子によって表される変数は、値が同じであることもあれば、値が異なることもある。
【００２６】
また、ここに記載する動作（ｏｐｅｒａｔｉｏｎ）は、コンピュータシステムのユーザーによって直接入力されるコマンドか、アプリケーション固有のハードウェアモジュールによって実行されるステップからなることもあるが、本発明は、ソフトウェアモジューによって実行され得るステップも含む。ここに記載するステップの機能は、モジュールの機能またはモジュールの一部の機能に相当し得る。
【００２７】
ここに記載する動作は、例えば、モジュールまたはモジュールの一部（例えば、ソフトウェアモジュール、ファームウェアモジュールまたはハードウェアモジュール）であり得る。ここに記載する実施形態は、ソフトウェアモジュールおよび手入力されたユーザーコマンドの少なくともいずれかを含み得るが、種々のモジュールの例は、アプリケーション固有のハードウェアモジュールであってもよい。ここに記載するソフトウェアモジュールは、スクリプト、バッチ、またはその他の実行可能ファイル、あるいはこれらのファイルの組み合わせやこれらのファイルの一部であってもよい。ソフトウェアモジュールは、コンピュータ可読媒体に符号化されたコンピュータプログラムまたは当該プログラムのサブルーチンであり得る。
【００２８】
さらに、モジュール間の境界は、単に例として採り上げたものに過ぎず、別法による実施形態においては、複数のモジュールを結合しても、モジュールの機能を別の方法によって分解してもよいことを当業者は理解する。例えば、ここに記載するモジュールを、複数のサブモジュールに分解して、複数のコンピュータプロセスとして実行してもよい。さらに、別法による実施形態では、特定のモジュールまたはサブモジュールを複数結合してもよい。さらに、当業者は、例示的な実施形態に記載した動作が例に過ぎないということを理解する。本発明に従って、動作を結合しても、動作の機能を別の動作に分散させてもよい。
【００２９】
ここに記載する各アクションは、モジュール（例えば、ソフトウェアモジュール）、モジュールの一部、またはコンピュータシステムのユーザーによって実行され得る。このため、上記の方法、その動作、およびそのためのモジュールは、本方法の動作を実行するように構成されるか、コンピュータ可読媒体から実行されるように構成されたコンピュータシステムで実行され得る。本方法を実行するようにコンピュータシステムを構成するために、本方法は、機械可読媒体およびコンピュータ可読媒体の少なくともいずれかとして実施し得る。このため、コンピュータシステムを構成して、モジュールの機能を実行するために、ソフトウェアモジュールをコンピュータシステムメモリに保存するか、同メモリに転送してもよい。上記の内容は、ここに記載する他のフロー図にも該当する。
【００３０】
ここに記載するソフトウェアモジュールは、例えば、コンピュータシステムによってコンピュータ可読媒体から受信され得る。コンピュータ可読媒体は、恒久的に、取り外し自在に、またはリモートにコンピュータシステムに結合され得る。コンピュータ可読媒体は、例えば、磁気記憶媒体、テープ記憶媒体、コンパクトディスク等の光学記憶媒体（例えば、ＣＤ−ＲＯＭ、ＣＤ−Ｒ等）、ディジタルビデオディスク記憶媒体、不揮発性メモリ記憶メモリ（半導体ベースのメモリユニット、ＦＬＡＳＨメモリ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、ＲＯＭまたはアプリケーション固有の集積回路）、揮発性記憶媒体（レジスタ、バッファ、キャッシュ、メインメモリＲＡＭ等）、コンピュータネットワーク、ポイント−ツー−ポイント通信、搬送波伝送媒体等のデータ転送媒体などであり得るが、これらに限定されない。ＵＮＩＸ（登録商標）をベースとした実施形態においては、ソフトウェアモジュールはファイルとして実施され得、これは、装置、端末、ローカルファイルまたはリモートファイル、ソケット、ネットワーク接続、信号などの通信方法または状態変化であ
り得る。その他の新規もしくは種々の種類のコンピュータ可読媒体を使用して、ここに記載するソフトウェアモジュールを記憶または伝送してもよい。
【００３１】
図２は、ユーザー空間に移されたオペレーティングシステムの機能の一部の例と、この環境において通常実施されるユーザープロセスの例を示す。ユーザー空間に移されたオペレーティングシステムの機能には、ローダー２１０（ユーザーアプリケーションをロードして実行を開始する）、ファイリングシステム２２０（ファイルを整然と記憶して取得できるようにする）、ディスクドライバ２３０（ハードディスク記憶装置等との通信を可能にする）、端末ドライバ２４０（マイクロカーネル１００など、図２に示すプロセスを実行しているコンピュータに接続している少なくとも１台のユーザー端末との通信を可能にする）等がある。従来はオペレーティングシステムの機能として分類されないその他のプロセスもユーザー空間で実行され得、この例として、本図にはウィンドウマネージャ２５０（グラフィカルユーザーインターフェイス［ＧＵＩ］の動作および表示を制御する）およびユーザーシェル２６０（例えば、オペレーティングシステム［マイクロカーネル１００など］またはコンピュータで実行されている他のプロセスに対して、コマンドラインまたはグラフィカルユーザーインターフェイスを許容する）が記載されている。図２に記載したユーザープロセス（アプリケーション）には、スプレッドシート２７０、ワードプロセッサ２８０、およびゲーム２９０がある。当業者にとって自明なように、膨大な数のユーザープロセスをマイクロカーネル１００で実行することができる。これは、プリエンプト不可能なスレッドを提供することの有用性、さらに一般化すれば、スレッドプリエンプト化可能であることを制御する有用性を示すものである。
【００３２】
図２に示すようなオペレーティングシステムアーキテクチャにおいては、ドライバおよびその他のシステムコンポーネントは、マイクロカーネルには含まれない。このため、入力／出力（Ｉ／Ｏ）要求が、メッセージ交換システムを使用してドライバに伝えられる。要求の送信元がマイクロカーネルをコールし、マイクロカーネルがこの要求をドライバ（あるいはその他のタスク）にコピーして、この要求を処理するために、タスクをユーザーモード実行に切り替える。この要求の処理を完了すると、マイクロカーネルは、結果を送信元のタスクにコピーして、ユーザーモードコンテキストが送信元のタスクに切り替えられる。このため、このようなメッセージ交換システムを使用することによって、ドライバ（例えば、ディスクドライバ２３０）がマイクロカーネルからユーザー空間内のタスクに移動できるようになる。
＜ディレクティブの例＞
マイクロカーネル１００に定義されているディレクティブには、例えば、スレッド作成ディレクティブ（Ｃｒｅａｔｅ）、スレッド消去ディレクティブ（Ｄｅｓｔｒｏｙ）、メッセージ送信ディレクティブ（Ｓｅｎｄ）、メッセージ受信ディレクティブ（Ｒｅｃｅｉｖｅ）、データ取得ディレクティブ（Ｆｅｔｃｈ）、データ保存ディレクティブ（Ｓｔｏｒｅ）、応答ディレクティブ（Ｒｅｐｌｙ）がある。これらのディレクティブを使用することによって、スレッドの操作、メッセージの交換およびデータ転送を行うことが可能となる。
【００３３】
Ｃｒｅａｔｅディレクティブを使用すると、マイクロカーネル１００によって、コール元スレッドのプロセス内に新しい実行スレッドが作成される。一実施形態においては、Ｃｒｅａｔｅコマンドは、コール元スレッドの全ての属性を、新たに作成されるスレッドにコピーする。これと対応するＤｅｓｔｒｏｙディレクティブを使用すると、マイクロカーネル１００によって、コール元スレッドが消去される。Ｄｅｓｔｒｏｙディレクティブの出力パラメータは、Ｄｅｓｔｒｏｙディレクティブが失敗したときにのみ返され、Ｄｅｓｔｒｏｙディレクティブが成功した場合は、コール元スレッドが消去されて、Ｄｅｓｔｒｏｙコールから結果（または制御）を返されるスレッドがない。
【００３４】
Ｓｅｎｄディレクティブを使用すると、マイクロカーネル１００によって、コール元スレッドの実行が停止されて、入力／出力（Ｉ／Ｏ）動作が開始される。Ｉ／Ｏ操作が完了すると、コール元スレッドが再開される。このように、メッセージがコール元スレッドによって送信される。コール元スレッドがメッセージを相手スレッド送信して（あるいはＤＭＡ、割込などの場合はメッセージが送信されるようして）、次に、Ｒｅｃｅｉｖｅディレクティブを使用して通信結果を返す。
【００３５】
Ｒｅｃｅｉｖｅディレクティブを使用すると、コール元スレッドのプロセスのＩ／Ｏチャネルのうちの１つに入力Ｉ／Ｏ動作が提示されるまで、マイクロカーネル１００によって、コール元スレッドの実行が停止される（あるタスクが他のタスクや他のソースからメッセージを受信できるようにする抽象化）。コール元スレッドのプロセスのＩ／Ｏチャネルのうちの１つに、スレッド制御ブロックがキューイングされるまで待機することによって、コール元スレッドによりメッセージが受信される。
【００３６】
Ｆｅｔｃｈディレクティブを使用すると、マイクロカーネル１００（または後述するスタンドアロンのｃｏｐｙプロセス）によって、受信側に送信されたデータが、コール元のアドレス空間のバッファにコピーされる。これに対応するＳｔｏｒｅディレクティブを使用すると、マイクロカーネル１００（または後述するスタンドアロンのｃｏｐｙプロセス）によって、Ｉ／Ｏ送信元のアドレス空間にデータがコピーされる。Ｒｅｐｌｙディレクティブを使用すると、マイクロカーネル１００によって、応答状態が、メッセージの送信元に返される。コール元スレッドはブロックされず、送信元のスレッドが開放されて実行できるようになる。
【００３７】
上記のディレクティブによって、タスクが効果的かつ効率的にデータを転送し、スレッドおよびメッセージを管理できるようになる。この種のディレクティブに関する詳細は、米国特許出願第０９／４９８，６０６号「簡略化したマイクロカーネルアプリケーションプログラミングインターフェイス」に記載されている。同発明は、Ｎ．Ｓｈａｙｌｏｒ（シェイラー）によって発明され、本発明の譲受人であるサン  マイクロシステムズ  インコーポレイテッドに譲渡されており、あらゆる目的のために参照によりその内容がここに援用される。タスク間通信にメッセージの使用、ならびに共通のオペレーティングシステムの機能を下記に簡単に記載する。
＜メッセージ交換アーキテクチャ＞
図３に、メッセージ３００の構造の例を示す。上記したように、メッセージ３００などのメッセージは、Ｓｅｎｄディレクティブによって１つのタスクから別のタスクに送信され、Ｒｅｃｅｉｖｅディレクティブによってタスクにより受信される。マイクロカーネル１００が採用しているこのアーキテクチャは、マイクロカーネル１００を介して送られるメッセージによってタスク同士が通信するメッセージ交換アーキテクチャに基づいたものである。メッセージ３００は、マイクロカーネル１００でのタスク間通信に使用される構造の例である。メッセージ３００には、Ｉ／Ｏチャネル識別子３０５、動作コード（ｏｐｅｒａｔｉｏｎ  ｃｏｄｅ）３１０、結果フィールド３１５、引数フィールド３２０，３２５、およびデータ記述レコード（ＤＤＲ）３３０を有する。Ｉ／Ｏチャネル識別子３０５は、メッセージを受信するタスクのＩ／Ｏチャネルを示すために使用される。動作コード３１０は、メッセージの送信元によって要求されている動作を示す。結果フィールド３１５は、メッセージにおいて要求されているアクションの結果を、メッセージの送信元に報告するためにメッセージの受信側タスクによって使用される。同様に、引数フィールド３２０，３２５は、受信側が要求したアクションを実行できるように、送信側が受信側にパラメータを渡すために使用される。ＤＤＲ３３０には、送信側タスクから受信側タスクに送信されるデータ（必要であれば）が格納される。当業者にとって自明なように、引数フィールド３２０，３２５は、パラメータとして扱っているが、引数フィールド３２０，３２５を少量の特定のデータの格納先としてみなすこともできる。
【００３８】
メッセージ交換に関する詳細は、米国特許出願第０９／６５０，３７０号（整理番号ＳＰ−３６９７  ＵＳ）「論理的データ空間の記述のための一般的データ構造」に記載されている。同発明は、Ｎ．Ｓｈａｙｌｏｒ（シェイラー）によって発明され、本発明の譲受人であるサン  マイクロシステムズ  インコーポレイテッドに譲渡されており、あらゆる目的のために参照によりその内容がここに援用される。また、メッセージ交換の詳細は、上記の特許出願「簡略化したマイクロカーネルアプリケーションプログラミングインターフェイス」にも記載されており、同出願は上記したようにここに援用される。
【００３９】
図４にＤＤＲ３３０の構造の例を示す。ＤＤＲ３３０は、型フィールド４１０、インラインデータフィールド４２０、コンテキストフィールド４３０、ベースアドレスフィールド４４０、オフセットフィールド４５０、長さフィールド４６０を有する制御データ領域４００と、任意選択のインラインバッファ４７０とを有する。型フィールド４１０は、受信側タスクにデータを送信するため、ＤＤＲ３３０によって使用されるデータ構造を示す。インラインデータフィールド４２０は、送信されるデータがＤＤＲ３３０内に格納されている場合（すなわち、データが任意選択のインラインバッファ４７０内の「インラインデータ」である場合）に使用される。別法として、インラインデータフィールド４２０を、インラインデータの存在の有無のみならず、データの量を示すために使用してもよい。任意選択のインラインバッファ４７０に少量（例えば、３２バイト、６４バイト、または９６バイト）のデータを格納する方法は、効率のよい少量のデータの転送方法である。事実、この構造を使用して少量のデータを転送するように、マイクロカーネル１００を最適化してもよい。これに対し、任意選択のインラインバッファ４７０を使用して大量のデータを転送することは困難（時には不可能）であり、大量のデータは、好ましくは、例えばここに援用される上記の特許出願「論理的データ空間の記述のための一般的データ構造」に記載されてているデータ構造のうちのいずれかを使用して転送する。同出願は、ＤＤＲ３３０に関して詳しく記載している。
（ユーザータスク内での任意選択のスレッドプリエンプト化）
上記のように、タスクは、内部からみると、少なくとも１つの実行スレッド（スレッド）から構成される。マルチスレッド化タスクおよび同期スレッド（さらに、任意選択のスレッドプリエンプト化さえも）が、システムアーキテクチャによってサポートされている場合、所定のタスク内のスレッドは同期的であり得る（タスク内のスレッドはプリエンプト可能ではなく、このため、互いにプリエンプトしない［すなわち、別のスレッドによってコンテキスト切替が発生することがない］）。スレッドプリエンプト化が任意選択の場合は、所定のタスク内のスレッドが非同期的であってもよい（タスク内のスレッドがプリエンプト可能であり、互いにプリエンプトする［すなわち、別のスレッドによってコンテキスト切替が発生する］）。このようなタスクは、それぞれ同期的、非同期的であると呼ばれる。
【００４０】
プリエンプト化の結果として、主として、コンテキスト切替が実施されて、プリエンプトされるスレッドのコンテキストから、プリエンプトするスレッドのコンテキストへ切り替わる。このため、非同期タスクにおいては、スレッドが互いにプリエンプトすることがあり、あるスレッドによって、別のスレッドからこのスレッドへのコンテキスト切替が、別のスレッドが自発的に制御を放棄することなしに強制的に起こる。これに対して、同期タスクにおいては、スレッドが互いにプリエンプトし、あるスレッドによって、別のスレッドからこのスレッドへのコンテキスト切替が、別のスレッドが自発的に制御を放棄することなしに強制的に起こることはない。これが起こるのは、プリエンプトされるタスクが、実行時に明確に定義された点（ｗｅｌｌ−ｄｅｆｉｎｅｄ  ｐｏｉｎｔ）に到達し、システムコールを行った（例えば、スレッドの実行により、制御がカーネルに移される点など）場合である。これに対して、スレッドがプリエンプト可能なタスクにおいては、第１スレッドが明確に定義された点に到達していなくても、システムコールを行なわなくても
、タスク内の別のスレッドが第１スレッドをプリエンプトすることができる。つまり、プリエンプト不可能なスレッドが制御（実行）を放棄することがあるが、制御を奪われることはないということができる。
【００４１】
したがって、（「ハードコード」されている場合であっても、何らかの方法によって任意選択可能な場合であっても）スレッドプリエンプト化をサポートしているシステムアーキテクチャにおいては、タスクがコンテキスト切替（すなわちプリエンプト化［非同期操作］）を許容するように構成されているときにのみ、タスク内での（所定のタスク内のあるスレッドから、同じタスク内の別のスレッドへの）コンテキスト切替が許容される。タスクが同期的に構成されている場合は、各スレッドはプリエンプト不可能であって、実行を待機する必要があるため、一度に１つのスレッドしか実行することができない。タスク内で同期機構を必要とすることなくスレッドの利点が得られ、それ故システムアーキテクチャが簡単になる。システムアーキテクチャ内の少なくとも１つのタスク（または全タスク）を同期的に設定できる一方で、タスク内でプリエンプト不可能とすることを任意選択できる（すなわちタスクが同期的、非同期的であるかを構成できる）ことが好ましいと考えられる。
【００４２】
カーネルは、好ましくはスレッドプリエンプト化をサポートしている（すなわち、ユーザーが、所定のプロセスにおいてスレッドがプリエンプト可能であるかどうかを選択できる）べきであると本発明者は考える。このような機能によって、プリエンプト不可能なスレッドを使用しているタスクがアトミックな命令（ｍｕｔｅｘロックなど）を使用しないように回避できるが、スレッドが実行を待つ遅延が増大することがある。
【００４３】
所定のタスク内のスレッドをプリエンプト不可能なように（すなわち同期的に）構成することが可能であるが、タスクは、相互にプリエンプト可能であり（または少なくともプリエンプト可能であり得）、プリエンプト可能であり続ける。このように、あるタスクが別のタスクをプリエンプトできる場合であっても、実行される同期が、所定のタスクのスレッド間での同期であって、プリエンプト使用不可にした場合には、このタスク内のあるスレッドが別のスレッドをプリエンプトできない。このため、あるタスクが別のタスクをプリエンプトでき、これは、別のタスクがプリエンプト不可能なスレッドのうちの１つを実行している（このためスレッドプリエンプト化が所定のタスク内でのみ有効）場合であっても可能である。
【００４４】
上記のように、プリエンプト可能なスレッドに関する問題として、複数のスレッドが互いにプリエンプトするためにタイミング起因エラー（すなわちすなわち「バグ」）が発生する点、もしくは少なくともタイミング関連エラーの再現、確認および訂正が困難である点がある。上記したように、タイミング起因エラーは、非同期的（時間と順序に無関係）な入力（例えば、割込またはスレッドの実行順序）の状態が一因となって発生する。スレッドをプリエンプト不可能に（すなわち同期的に）設定することによって、この種のタイミング起因エラーおよびその他のタイミング関連エラーの発生を阻止することができる。
【００４５】
同期タスク（すなわちプリエンプト不可能なスレッド）を提供できることは、多くの理由から重要である。タスクを同期的にする場合（すなわち、スレッドプリエンプト化が許可されない場合）、一般にある分類の全エラー（タイミング関連エラー）を除去できるため、エラーが減る。上記のように、タイミング関連エラーの回避は、幾つかの点において重要であり、これについては下記で詳細に記載する。タイミング関連エラーを回避することに加えて、タスクのスレッドを同期できることにより、同期スレッドのコードが簡単になる。例えば、キューにエントリを挿入するためのコードの場合、エントリを挿入するプロセスが、完了前に同じプロセスの別のスレッドによってプリエンプトされることがないことがわかっていれば、コードを簡単にすることができる。下記に、キュー（本例におい
ては、双方向リスト）への挿入を実行する擬似コードを下記に記載する。
【００４６】
before_tmp_ptr =  挿入点の前のエントリ; 
after_tmp_ptr = 挿入点の後のエントリ; 
before_tmp_ptr.forward_prt = new_entry; 
after_tmp_ptr.back_prt = new_entry; 
new_entry.back_ptr = before_tmp_ptr;
new_entry.forward_ptr = after_tmp_ptr;
上記の命令において（プリエンプトにより）割込が発生した場合、このキューが破損することがあり、このキューが別のスレッドによってアクセスされるとエラーが発生し得る（発生する可能性が高い）ということが当業者にとって自明である。このため、タスクが非同期的な場合、このようなコード部分（一般にコードの「競合禁止部分（ｃｒｉｔｉｃａｌ  ｓｅｃｔｉｏｎ）」と呼ばれる）も同様に保護する必要がある。この保護は、例えば、タスク内のコンテキスト切替を無効にするロックセマフォを使用し、この点に関してコードの保護対象部分をアトミックにすることによって実現できる。
【００４７】
割込の点からこの例を検討する場合、プリエンプトされるのは挿入を実行するスレッドであって（プロセスの別のスレッドがキューにアクセスしようと試行する前に、挿入プロセスを完了できないこともある）、別のタスクによってこのスレッドが属するタスクがプリエンプトされるのではない。上記のように、挿入を実行するタスクが挿入処理を完了することができない場合、キューが破損することがあり、タスクがこのキューにアクセスしようとするとクラッシュするため、プログラマは上記のような競合禁止部分を保護する必要がある。
【００４８】
しかし、同期スレッドの場合は、挿入を実行するスレッドがプリエンプトされることがないため、保護命令が不要となる。このように、保護命令が不要であるという理由と、プログラマがコードの競合禁止部分をみつけ出して確認する（当業者にとって自明なようにこれは困難なことが多い）必要がないという理由とによって、この動作のコーディングが簡単になる。
【００４９】
保護命令（すなわち、コードの一部をアトミックにする命令）が必要な場合であっても、保護命令をユーザー空間で実行するようにし、実行にカーネルが関与しないようにすれば、簡単であり時間がかからない。例えば、Ｓｅｎｄ命令を保護する場合、通常は割込を無効にする（例えば、ｄｉｓａｂｌｅ（）コールとｅｎａｂｌｅ（）コールとを使用する）。ｄｉｓａｂｌｅ（）コールおよびｅｎａｂｌｅ（）コールは、これらのコールをオペレーティングシステムに対して行う場合と比べて、ユーザー空間で実行した場合は簡単であり時間がかからない。
【００５０】
事実、同期スレッドを使用することによって、タスク全体を簡単にできる。例えば、１つのユーザータスク（すなわち、ここに記載したオペレーティングシステムの例においては、ユーザー空間でプロセスとして実行される１つのタスク）は、ファイルシステムが管理するプロセスである。このようなプロセスは、大半の時間、各種のイベント（ユーザーまたはユーザープロセスからのコマンド、Ｉ／Ｏサブシステムからのデータなど）を待機している待ち状態にあり、ブロックされており、通常は非同期的である。プリエンプト化を無効にした場合、この種のイベントはファイルシステムプロセスの実行時に明確に定義された点において処理されるため、この種のイベントが非同期的であっても問題とならない。
【００５１】
しかし、一部のローカルなロック機構（ローカルとは、所定のタスクおよびスレッドがローカルであることを指す）が必要となることもある。例えば、ファイルシステムは典型
的にはコマンドの受信を待機し、続いてこのコマンドを処理する。ある種のコマンドは、必ずしも成功裏に完了するわけではなく、成功完了を前提にできないものもある。このようなコマンドの１つに、ディレクトリの削除コマンドがある。ディレクトリの削除コマンドは、他の多くのコマンドと同様に、コマンドの成功完了を前提にできない（例えば、何らかの理由によって、１つ以上のファイルが削除されない場合、そのファイルが格納されているディレクトリを削除することができない）。ディレクトリが成功裏に削除されるまでディレクトリを保護するために、「ｌｏｃｋ  ｄｉｒｅｃｔｏｒｙ」コマンド（ディレクトリおよびその中のファイルの削除を開始する前に実行）および「ｕｎｌｏｃｋ  ｄｉｒｅｃｔｏｒｙ」コマンド（削除後に実行）などのコマンドを使用することができる。このようなコマンドは、成功、失敗のいずれであるか問わず、削除動作が完了するまで、ディレクトリへのアクセスまたはディレクトリの削除を阻止する。コードの一部をアトミックにするための代表的な命令に比べて、本例のローカルなロックは極めて軽い（例えば、このロックは、削除対象のディレクトリにアクセスする前に、タスク内の他のスレッドがチェックするフラグと同じ位単純であり得る）。
【００５２】
別の例として、デバイスドライバ（ハードディスクドライバなど）がある。このドライバは、本明細書で採り上げたオペレーティングシステムの例、マイクロカーネル１００において装置（例えば、ハードディスクドライブ）をサポートするように設計され得る。ハードディスクドライブおよびそのデバイスドライバの場合、コマンドが直列的に実行されて、データが直列的に送信および取得される。いかなる場合でも一度に１つのアクションしか実行できないため、ハードディスク用のデバイスドライバのタスクを非同期タスクとして構成することは妥当である。このようなプロセス内のスレッドがプリエンプト不可能であることは、単にこのタスクがその用途を反映（ｍｉｒｒｏｒ）できるようにすることである。当然、これは、プリエンプトするスレッドに制御を渡す前に、各スレッドが明確に定義された点に到達できるため有益である。この点において、オペレーティングシステムは単に処理すべき次のイベントに進み、続いて処理すべき次のスレッドに進むだけである。これは、ドライブが一度に１つのアクションのみを実行すればよいため、デバイスドライバからみて望ましい。事実、ハードウェアが一度に１つのタスク／プロセス、１つのイベントのみを実行できるため、これは、数多くの周辺機器の機能を反映（ｍｉｒｒｏｒ）している。
【００５３】
ここでもまた、上記のように、プリエンプト可能なスレッドの問題点として、複数のスレッドが互いにプリエンプトすることによって、タイミング起因エラーが発生することがある。非同期入力およびスレッドの実行順序などのパラメータを制御することは不可能ではないが非常に困難であるため、この種のエラーを分離して確認することは極めて難しい。このため、この種のエラーを検出および訂正できる機能は望ましい。さらに、マルチスレッドされた化プロセスの複数のスレッドが独立して実行して（互いにプリエンプトできるようにする）場合には、タイミング起因エラーの検出および訂正が簡単になることが望ましい。
【００５４】
このため、任意選択のスレッドプリエンプト化により、プログラムの設計およびコーディングにおけるエラーの検出および訂正（一般にデバッグと呼ばれる）が簡単になる。上記のように、非同期コードに競合禁止部分が存在することにより、コーディング作業とデバック作業の両方が非常に複雑となる。しかし、任意選択のスレッドプリエンプト化をサポートしているシステムにおいては、タスクのスレッドをプリエンプト不可能に構成すれば、プログラミングが簡単になるほか、プリエンプト可能モードとプリエンプト不可能モードとを切り替えることで、タイミングによって発生するエラー（すなわち、スレッドプリエンプト化などのタイミング関連のバグ）を捕捉できるようになる。このため、プログラミング工程において同期スレッドの使用を、段階的にすることができる。このような場合、まずは、プログラムを同期的に実行させて、コーディングおよびデバックを行う。同
期スレッドでプログラムが正しく動作するようになったら、スレッドを非同期的に動作するように設定して、この種のエラー（タイミング関連エラー）を出現させる。タスクのプリエンプト化／非プリエンプト化を切り替えて、この種のエラーをみつけ出し特定し易くする。
【００５５】
上記の選択可能機能を提供することは、ユーザー側に提供される機能（すなわち、スレッドプリエンプト化、特に任意選択のスレッドプリエンプト化のサポート）によって簡単にできる。上記の任意選択のスレッドプリエンプト化は、例えば、各タスクが、そのタスクが同時に実行可能なスレッドの数を示す値（典型的には１または無制限であるが、他の値を使用してもよい）を有するようにすれば実現することができる。この値は、許容可能な並行実行スレッドの数とも呼ばれる。
【００５６】
このため、タスクは、所望の割合（ｒａｔｅ）でスレッドを作成することができると共に、任意の数のスレッドを作成することができる。ただし、タスクが実行しているスレッドの数が並行スレッドの上限に達した場合、タスクは待機する必要がある。並列に実行されているスレッドの数が上限に達していない場合にのみ、イベントがスレッドの状態を「実行可能」に構成することができる。この上限に達した場合、実行すべきスレッドは、実行可能なスレッドのキューに入れられる。このキューは、実行可能であるが、タスクの並行スレッドの上限に達しているため実行できないタスクを格納している。このように、各タスクは、そのタスクが同時に実行可能なスレッドの数を示す値（典型的には、１つのスレッドのみを実行できることを示す数、または任意の数のスレッドを実行できることを示す数［すなわち無制限］）を有する。
【００５７】
この機能は、カーネル内の次の構造によってサポートされる。一実施形態においては、イベントを待機しているスレッド用のキュー、実行可能なスレッド用のキュー、および実行中のスレッド用のキューの３つのキューが設けられる。スレッドが「実行可能なスレッド」のキューから実行中のスレッドのキューに移動されるためには、タスクの上限に到達していない必要がある。上限に達した場合、スレッドは、実行中のスレッド用のキューに空きが生じ、スレッドの実行が許可されるまで、実行可能なスレッドのキューで待機する。このような機能を提供するオペレーティングシステムの例が、本出願に援用され、本出願に添付のＣＤ−ＲＯＭの付録に収録されている。
【００５８】
当業者にとって自明なように、プリエンプト化を選択できる機能をサポートすることが好ましいことが多い。仮に、本発明の諸実施形態によるシステムに、上記のような選択可能機能が提供されていなければ、タスクのスレッドが、プリエンプト可能（複数のスレッドを多数のプロセッサに分散して実行させることができる）であるか、プリエンプト不可能（アトミックな命令が不要となり、このタスクのプログラミングが簡単になる）であるかを設定しなければならなくなる。さらに、アプリケーションのコーディングにおいて、上記のようなタイミング関連の問題を検討する必要がなくなるため、複数のスレッドを強制的に同期的に実行させることで、プログラミングを簡単にできる。しかし、前者の手法では、（この種のプログラミング上の複雑さをユーザーから隠蔽することができない［例えば、コード部分をアトミックにする命令が必要となる］ため）、所定のプロセス内でのプログラミングが複雑となり、このプロセスでタイミング関連エラーが発生する可能性がある。これに対し、後者の手法では、各タスクを単一のプロセッサで実行させるため、低レベル（スレッドレベル）のマルチタスキングが行われない。このように、プリエンプト化と非プリエンプト化とのいずれかを選択できる機能によって、プログラマが柔軟な手法を採用して、この側面をタスクに合わせることができるようになると共に、プログラムのコーディングが簡単になる。
【００５９】
有利なことに、プリエンプト化可能であることを動的に構成することができる（上記の
とおり）。動的構成を使用することによって、単一のプロセッサで非同期的に実行されているタスクを、このタスクを別のプロセッサに移動させる前準備として（タスクを移動しやすくするため）同期的にすることができる。他のプロセッサへの移動が成功したら、このタスクを、非同期動作に再度切り替える。これは、特に対称マルチプロセシング（ＳＭＰ）環境において有用である。
【００６０】
プリエンプト不可能なスレッドを提供できることは、ＳＭＰ環境において特に有用である。スレッドを任意選択でプリエンプト可能に設定できる機能は、単なる論理的な構造としてユーザー（プログラマ）に提供される。これは、単純であるため、特にＳＭＰ環境において有用である。プリエンプト不可能なスレッドを使用する場合、一度に複数のスレッドを実行することができず、実行できるのは各タスクにつき１つのスレッドのみである。スレッド間のプリエンプト化を許容する場合、タスクが、ＳＭＰプロセッサのうちのいずれかで実行されるスレッドを複数有することができ、タスクを複数のプロセッサに分散できる。プリエンプトを無効にする場合、各タスクは、基本的には（常に実行できるのは１つのタスクのスレッドのみであるため、少なくともＳＭＰ環境のコンテキスト内においては）単一のスレッドであるとみなすことができる。このようなタスクは単一のスレッドとして実行され、ＳＭＰプロセッサのうちのいずれか１つで実行される。１つのタスクのみがＳＭＰプロセッサのうちのいずれか１つで実行されるという点、および各タスクがプロセッサのうちのいずれか１つでのみ実行されるという点は、数多くの利点を有する。
【００６１】
ＳＭＰ環境での任意選択のスレッドプリエンプト化の利点として、プログラムの設計およびコーディングにおけるエラーの検出および訂正（一般にデバッグと呼ばれる）が簡単になるという点がある。典型的には、プログラムのデバックの際には、全てのタスク／スレッドにｓｔｏｐメッセージを送信して、これらのタスク／スレッドの実行を停止し、プログラム中で（一般には、プログラム中のブレークポイントと呼ばれる点において）、デバッガ（プログラムのエラーを確認および訂正するために一般的に使用されるプログラム）に制御を移す必要がある。通常、プリエンプト可能なタスクでは、実行のどの点にいる場合であっても、ｓｔｏｐ信号を受信したタスク／スレッドによって、この信号が処理される。この点は、各スレッドの実行のタイミング、ｓｔｏｐ信号が各プロセッサに伝えられるために必要な時間、その他の現象によって、タスク毎、スレッド毎に変わることがあるため、各スレッドの状態を正確に知ることは困難である。さらに、タスクが任意の点で複数のスレッドを有する可能性があるため、停止処理は、複数のスレッドを実行しているタスクに関しては、さらに複雑である。
【００６２】
しかし、プリエンプト不可能なスレッドを使用することによって、１つのスレッドのコードにブレークポイントを挿入して、このブレークポイントに到達したときに、このスレッドを実行しているプロセッサの実行を停止することができる。このプロセッサで実行しているタスクは、内部的にプリエンプト不可能であるため、所定のタスクについて任意の時点で実行されているタスクは１つしかなく、１つのスレッドのみが実行を停止する。このため、何時でも１つのスレッドのみが実行されているため、他のプロセッサで実行しているスレッドを停止する必要はない。さらに、必要に応じて、各スレッドを、明確に定義された点で停止することもできる。
【００６３】
別の利点として、スレッドおよびタスクが特定のＣＰＵで実行されないＳＭＰシステムにおいて、同期タスクをあるＣＰＵから別のＣＰＵに容易に移動することができる点がある。これは、同期タスクを移動する際に、維持すべきコンテキストが１つのみであるためである。事実、動的構成を使用することによって、単一のプロセッサで非同期的に実行されているタスクを、このタスクを別のプロセッサに移動させる前準備として（タスクを移動しやすくするため）同期的にすることができる。他のプロセッサへの移動が成功したら、このタスクを、非同期動作に再度切り替える。ここでも、これは、タスクを同期的にす
ることによって、一度に１つのスレッドのみが実行されるためである。
【００６４】
当業者にとって明白なように、上記の点を鑑みれば、任意選択のスレッドプリエンプト化には数多くの利点がある。命令の数が少ないため、同期的に実行されるコードの実行がより高速になる。同期スレッドを使用することにより、スレッドが相互に分離され、タイミング関連エラーを回避できると共に、保護命令を使用せずに済むため、一般に、短時間でプログラムを記述して、正しく実行させることができる。同期タスクは、タスク内ではプリエンプト不可能であり、タスク間ではスレッドが別のタスクであるため、相互に分離されている。ここに記載したようなオペレーティングシステムにおいては、上記の分離は、タスク間相互作用の唯一の方法として、メッセージ交換を使用することによって維持される。
【００６５】
また、タスクのスレッドを、ケースバイケースでプリエンプト可能に構成することができる。これにより、複数のプロセッサでタスクを実行させることによる相当の利点が得られなければ、タスクのスレッドをプリエンプト不可能に構成することができる。このように構成して、アトミックな命令を使用しなくても済むようにした結果、コーディング作業が簡単になり、効率が向上する。さらに、これによって、上記のようにタイミング関連エラーを回避することができる。各スレッドが明確に定義された点（例えば、ディレクティブコール）で停止しなければならず、明確に定義された点においてコンテキスト切替が発生するため、タスク内での同期が必要なくなる。同期スレッドをサポートすることによって、非同期タスクの管理に要するオーバーヘッド（スレッド間での同期をサポートするデータ構造）をなくすことができる。例えば、同期スレッドをサポートする際に、同期ロックを行う必要がない。上記のように、プリエンプト化を、１つのタスク（タスク内プリエンプト化）についてのみならず、タスク間（タスク間プリエンプト化）で行うことも可能である。
【００６６】
スレッドプリエンプト化が任意選択である場合、プログラマは、タスクを同期的に記述および実行して、次に、タイミング関連エラーを確認するために、このタスクを、非同期的に実行されるように移行させることができる。上記の手法により、プログラミング上の制約が単純になるため、プログラミングが柔軟にできるようになる。
【００６７】
上記のように、マルチプロセッサ環境（例えば、ＳＭＰ環境）においては、タスク／スレッドを特定のプロセッサで実行する必要がない。複数のプロセッサでタスクを同時に実行させても、パフォーマンスの大幅な向上が見込まれない場合は、プリエンプト不可能が標準となるように設定して、上記の利点および恩恵を得ることができる。しかし、複数のプロセッサでタスクを同時に実行させれば、パフォーマンスの大幅な向上が見込まれる場合は、プリエンプト不可能に設定できる機能を使用して、上記のようにタスクのデバックおよび動作を簡単にすることができる。例えば、プログラムで、タスクのカウント（実行中のスレッドの数）を動的にゼロに構成して、実行中のタスクを停止することができる（ある時点において実行が停止する）。一定の時間が経過したら、タスク全体を休止させて、タスク全体をイメージにして、何も実行されていないようにする。
【００６８】
本発明の特定の実施形態を記載および図示したが、本明細書の教示に基づいて、本発明の範囲およびその広範な態様から逸脱することなく、本発明を変更および変形することができることが当業者にとって自明である。このため、添付の特許請求の範囲は、本発明の真の精神および範囲から逸脱することなく、変更例および変形例を含む。さらに、本発明は添付の特許請求の範囲によってのみ限定されることが理解される。
【図面の簡単な説明】
【００６９】
【図１】例示的なシステムアーキテクチャの構成を示す図。
【図２】種々のユーザータスクを有する例示的なシステムアーキテクチャの構成を示す図。
【図３】例示的なメッセージデータ構造の構成を示す図。
【図４】インラインでデータを提供するデータ記述レコードの例示的なデータ構造を示す図。
【図１】
2004288162.tif 000003
【図２】
2004288162.tif 000004
【図３】
2004288162.tif 000005
【図４】
2004288162.tif 000006
【外国語明細書】
2004288162.tif 000007
2004288162.tif 000008
2004288162.tif 000009
2004288162.tif 000010
2004288162.tif 000011
2004288162.tif 000012
2004288162.tif 000013
2004288162.tif 000014
2004288162.tif 000015
2004288162.tif 000016
2004288162.tif 000017
2004288162.tif 000018
2004288162.tif 000019
2004288162.tif 000020
2004288162.tif 000021
2004288162.tif 000022
2004288162.tif 000023
2004288162.tif 000024
2004288162.tif 000025
2004288162.tif 000026
2004288162.tif 000027
2004288162.tif 000028
2004288162.tif 000029
2004288162.tif 000030
2004288162.tif 000031
2004288162.tif 000032
2004288162.tif 000033
2004288162.tif 000034
2004288162.tif 000035
2004288162.tif 000036
2004288162.tif 000037
2004288162.tif 000038
2004288162.tif 000039
2004288162.tif 000040
2004288162.tif 000041