特許 7512498 メッセージ送受信方法およびオペレーティングシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-28

(45)【発行日】2024-07-08

(54)【発明の名称】メッセージ送受信方法およびオペレーティングシステム

(51)【国際特許分類】

   G06F 9/54 20060101AFI20240701BHJP

【ＦＩ】

G06F9/54 B

【請求項の数】 6

(21)【出願番号】P 2023148135

(22)【出願日】2023-09-13

(62)【分割の表示】P 2021110048の分割

【原出願日】2021-07-01

(65)【公開番号】P2023165009

(43)【公開日】2023-11-14

【審査請求日】2023-09-13

(73)【特許権者】

【識別番号】501100881

【氏名又は名称】イーソル株式会社

(74)【代理人】

【識別番号】100157912

【弁理士】

【氏名又は名称】中島 健

(74)【代理人】

【識別番号】100074918

【弁理士】

【氏名又は名称】瀬川 幹夫

(72)【発明者】

【氏名】大野 智史

(72)【発明者】

【氏名】権藤 正樹

【審査官】田中 幸雄

(56)【参考文献】

【文献】特開２０２１－６０７０７（ＪＰ，Ａ）

【文献】特開２０１６－４５５１０（ＪＰ，Ａ）

【文献】特開２０００－３４７８８１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５４

(57)【特許請求の範囲】

【請求項1】

複数のプロセッサコアと、前記複数のプロセッサコアがアクセス可能なメモリと、を備えたコンピュータが、オペレーティングシステムに実行させるメッセージ送受信方法であって、
前記オペレーティングシステムは、前記複数のプロセッサコアと１対１で対応して設けられた複数のマイクロカーネルを並行して実行可能であり、
前記複数のマイクロカーネルのそれぞれが、対応するプロセッサコアに割り当てられたスレッドの制御を行うように構成されており、
前記複数のマイクロカーネルのうちの少なくとも１つは、どのプロセッサコアにどのスレッドが割り当てられているかを管理するスレッド管理機能を備え、
前記メモリには、スレッドの生成時に、当該スレッドに固有のスレッドメッセージバッファが確保されており、
前記スレッドメッセージバッファにメッセージを書き込むことで、異なる前記マイクロカーネルに所属するスレッド間でメッセージングを実行可能とした、
メッセージ送受信方法。

【請求項2】

前記スレッドメッセージバッファのサイズは、スレッド生成時のパラメータにより指定可能である、
請求項１に記載のメッセージ送受信方法。

【請求項3】

前記オペレーティングシステムは、スレッド生成後に前記スレッドメッセージバッファのサイズを変更可能なＡＰＩを備えている、
請求項１または２に記載のメッセージ送受信方法。

【請求項4】

複数のプロセッサコアと、前記複数のプロセッサコアがアクセス可能なメモリと、を備えたコンピュータ上で実行されるオペレーティングシステムであって、
前記オペレーティングシステムは、前記複数のプロセッサコアと１対１で対応して設けられた複数のマイクロカーネルを並行して実行可能であり、
前記複数のマイクロカーネルのそれぞれが、対応するプロセッサコアに割り当てられたスレッドの制御を行うように構成されており、
前記複数のマイクロカーネルのうちの少なくとも１つは、どのプロセッサコアにどのスレッドが割り当てられているかを管理するスレッド管理機能を備え、
前記メモリには、スレッドの生成時に、当該スレッドに固有のスレッドメッセージバッファが確保されており、
前記スレッドメッセージバッファにメッセージを書き込むことで、異なる前記マイクロカーネルに所属するスレッド間でメッセージングを実行可能とした、
オペレーティングシステム。

【請求項5】

前記スレッドメッセージバッファのサイズは、スレッド生成時のパラメータにより指定可能である、
請求項４に記載のオペレーティングシステム。

【請求項6】

スレッド生成後に前記スレッドメッセージバッファのサイズを変更可能なＡＰＩを備えている、
請求項４または５に記載のオペレーティングシステム。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、複数のプロセッサコアを搭載したコンピュータ上で実行されるメッセージ送受信方法およびオペレーティングシステムに関する。

【背景技術】

【0002】

本出願人は、特許文献１において、複数のプロセッサコアを搭載したコンピュータ上で実行される同期制御システムおよび同期制御方法に関する発明を提案した。この特許文献１に記載された発明では、プロセッサコアごとにオペレーティングシステムのマイクロカーネルが実行されるようになっている。そして、このマイクロカーネルが、ロックオブジェクトを使用して、異なるプロセッサコアで実行されているスレッド間の排他制御や同期制御を行うようになっている。

【0003】

ところで、このようなロックオブジェクトを使用した制御は、排他制御や同期制御には便利であるが、スレッド間の同期だけでなく、何からの情報（メッセージ）を相手側に通知したい場合がある。

【0004】

メッセージの送受信の方法としては、メッセージバッファを使用したものが知られている（非特許文献１参照）。このようなメッセージバッファを使用した方法では、最初にメッセージバッファが作成される。その後、送信側がメッセージバッファ領域にメッセージを格納する。また、受信側はメッセージバッファ領域からメッセージを取り出す。なお、受信側がメッセージバッファ領域からメッセージを取り出そうとしたときに、まだメッセージが格納されていない場合は、受信側が受信待ち状態になる。また、送信側がメッセージを送信しようとしたときに、メッセージバッファ領域に空きがなくあふれてしまう場合には、送信側が送信待ち状態になる。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０２１－６０７０７号公報

【非特許文献】

【0006】

【文献】トロンフォーラム、「ＲＴＯＳ入門編」第４回タスク間同期・通信機能２、［online］、［令和３年６月２３日検索］、インターネット〈URL：https://www.tron.org/ja/page-722/rtos04/〉

【発明の概要】

【発明が解決しようとする課題】

【0007】

非特許文献１に記載されているようなメッセージバッファ機能を使用するには、送受信の前にメッセージバッファが確保されており、また、メッセージバッファの場所（ＩＤやアドレス）を、送信側および受信側のいずれもが共有して認識している必要がある。

【0008】

このため、特許文献１に記載されているような、プロセッサコアごとにマイクロカーネルを実行している環境において、マイクロカーネル間で同様の通信を行う場合にも、あらかじめメッセージバッファが確保されており、異なるプロセッサコアで実行されているマイクロカーネルのそれぞれが、メッセージバッファを特定するための情報を共有して認識している必要がある。

【0009】

この問題を解決する最も単純な方法は、マイクロカーネルごとにあらかじめメッセージバッファを確保しておく方法である。すなわち、異なるプロセッサコア間で通信を行う場合に、送信元のマイクロカーネルが、受信先のマイクロカーネルのメッセージバッファにメッセージを書き込むようにすれば、プロセッサコアを跨いだ通信が可能となる。

【0010】

しかしながら、上記したようにマイクロカーネルごとにあらかじめメッセージバッファを確保しておく方法では、システムの安全性を担保することが困難であった。例えば、メッセージの受信量が一時的に増加してメッセージの受信処理が間に合わなくなると、メッセージバッファがあふれてしまい、マイクロカーネルの全スレッドが停止しまうおそれがあった。

【0011】

なお、メッセージバッファのサイズを限りなく増加させれば上記したような問題は解消できる。しかしながら、メッセージバッファに使用できるメモリには上限があるため、この解決策は現実的ではない。

【0012】

別の解決策として、マイクロカーネルごとに必要となるメッセージバッファのサイズを正確に見積もることが考えられる。正確な見積もりが可能であれば、その分だけあらかじめメッセージバッファを確保することで、メッセージバッファの不足を回避できる。しかしながら、どのプロセッサコアでどのスレッドが実行されるかの予測が困難なシステムでは、必要となるメッセージバッファのサイズをあらかじめ見積もることは難しい。例えば、プロセッサコアを有効活用するためにスレッドのマイグレーションを行うシステム（詳しくは後述するが、優先度の高いスレッドが集中して実行されているプロセッサコアがある場合、一部のスレッドを他のプロセッサコアへと移動させることで、プロセッサコア間の負荷を自動的に調節するようなシステム）の場合、どのプロセッサコアでどのスレッドが実行されるかはわからないため、プロセッサコアごとのメッセージ量を見積もることはできない。このように、スレッドがマイグレーションするようなシステムにおいては、マイクロカーネルごとにあらかじめ適切なサイズのメッセージバッファを確保し、メッセージバッファの不足を回避することは困難である。

【0013】

また、スレッドには、高い安全性が求められるものと、そこまで高い安全性が求められないものとが混在している。このため、メッセージバッファが不足するとしても、高い安全性が求められるスレッドが停止しないように制御される必要がある。

【0014】

上記した点を踏まえ、本発明は、メッセージの受信量が一時的に増加した場合でも、高い安全性が求められるスレッドへの影響を最小限とすることできるメッセージ送受信方法を実現することを課題とする。

【課題を解決するための手段】

【0015】

上記した課題を解決するため、本発明は、複数のプロセッサコアと、前記複数のプロセッサコアがアクセス可能なメモリと、を備えたコンピュータが、オペレーティングシステムに実行させるメッセージ送受信方法において、前記オペレーティングシステムは、前記複数のプロセッサコアと１対１で対応して設けられた複数のマイクロカーネルを並行して実行可能であり、前記複数のマイクロカーネルのそれぞれが、対応するプロセッサコアに割り当てられたスレッドの制御を行うように構成されており、前記複数のマイクロカーネルのうちの少なくとも１つは、どのプロセッサコアにどのスレッドが割り当てられているかを管理するスレッド管理機能を備え、前記メモリには、スレッドの生成時に、当該スレッドに固有のスレッドメッセージバッファが確保されており、前記スレッドメッセージバッファにメッセージを書き込むことで、異なる前記マイクロカーネルに所属するスレッド間でメッセージングを実行可能とした。

【発明の効果】

【0016】

本発明は上記の通りであり、スレッドの生成時に、当該スレッドに固有のスレッドメッセージバッファが確保されている。このため、スレッドごとにメッセージが管理されており、高い安全性が求められないスレッドに対するメッセージが一時的に増加してバッファが枯渇した場合でも、高い安全性が求められるスレッドが影響を受けることはない。このため、メッセージの受信量が一時的に増加した場合でも、重要なメッセージを確実に送受信することができる。

【図面の簡単な説明】

【0017】

【図1】コンピュータシステムの概略を示すブロック図である。

【図2】各プロセッサコアに配置されたマイクロカーネルの概略を示す説明図である。

【図3】メッセージ送受信の概略を示す説明図である。

【図4】メッセージ送信処理のフロー図である。

【図5】割り込み発生時のメッセージ受信処理のフロー図である。

【図6】ＡＰＩ呼び出し時のメッセージ受信処理のフロー図である。

【発明を実施するための形態】

【0018】

本発明の実施形態について、図を参照しながら説明する。
（ハードウェア構成）
本実施形態に係るコンピュータシステムは、図１に示すようなコンピュータを備えている。このコンピュータは、ＣＰＵ１０、メモリ２０（主記憶装置）、図示しない補助記憶装置、を備えている。

【0019】

本実施形態に係るＣＰＵ１０は、１つのプロセッサパッケージ内に複数のプロセッサコア１１を搭載したマルチコアプロセッサである。図１に示すＣＰＵ１０は、６４個のプロセッサコア１１を搭載している。なお、この図１は例示に過ぎず、プロセッサコア１１の数はいくつであってもよい。また、ＣＰＵ１０は、必ずしも単一のプロセッサパッケージからなるものでなくてもよく、複数のプロセッサパッケージからなるように構成されていてもよい。

【0020】

メモリ２０は、ＣＰＵ１０が直接アクセスすることができる記憶装置であり、実行中のスレッドのコンテキストやその他のデータが記憶されている。例えばこのメモリ２０には、オペレーティングシステムの一部であるマイクロカーネル３０の実体としてのコンテキストデータや、オペレーティングシステムによって実行を制御されるスレッドの実体としてのコンテキストデータなどが配置されている。なお、これらのオペレーティングシステムやスレッドのプログラムは補助記憶装置に記憶されており、必要に応じてメモリ２０に読み込まれることで、ＣＰＵ１０によって使用可能となる。

【0021】

（オペレーティングシステムの概要）
オペレーティングシステムは、ＣＰＵ１０が実行するプログラムを制御するソフトウェアである。本実施形態に係るオペレーティングシステムは、複数のプロセッサコア１１を搭載したＣＰＵ１０（マルチコアプロセッサ）をサポートしている。このオペレーティングシステムでは、プログラムの実行単位をスレッドと呼んでいる。

【0022】

本実施形態に係るオペレーティングシステムは、マイクロカーネル型のオペレーティングシステムであり、オペレーティングシステムの基本的な機能の多くをマイクロカーネルとして提供している。オペレーティングシステムの基本的な機能であるマイクロカーネル３０は、上記した複数のプロセッサコア１１と１対１で対応して設けられ、各プロセッサコア１１において並行して実行される。具体的には、システム起動時にプロセッサコア１１ごとにマイクロカーネル３０のインスタンスが生成され、マイクロカーネル３０の機能を外部に提供するサーバースレッドが、対応するプロセッサコア１１（「自コア」と言う）上で常に実行される。

【0023】

各プロセッサコア１１に配置されたマイクロカーネル３０は、それぞれ、図２に示すような機能を備えている。すなわち、ローカルスケジューラ３１（スケジューリング機能）、メッセージマネージャ３４（メッセージ送受信機能）、割り込みマネージャ３５（割り込み管理機能）、インタフェースライブラリ３９などの機能を備えている。

【0024】

ローカルスケジューラ３１（スケジューリング機能）は、プロセッサコア１１におけるスレッドの切り替えを行う機能である。ローカルスケジューラ３１は、自コアに割り振られたスレッドの中から実行するものを選択し、選択したスレッドにプロセッサコア１１の実行権を与えるスケジューリングを行う。このローカルスケジューラ３１によって、複数のマイクロカーネル３０のそれぞれが、対応するプロセッサコア１１に割り当てられたスレッドの制御を行うように構成されている。

【0025】

メッセージマネージャ３４（メッセージ送受信機能）は、後述するメッセージ送受信モジュール４０を使用して、スレッド間やマイクロカーネル３０間でのメッセージ送受信を行うための機能である。メッセージマネージャ３４は、指定されたパラメータに従い、メッセージ送受信モジュール４０を介して、スレッドやマイクロカーネル３０へメッセージを送信する機能と、スレッドやマイクロカーネル３０から通知されるメッセージを受信する機能を持つ。また、このメッセージマネージャ３４は、送信先や受信先の解決を行う機能を有している。具体的には、メッセージ送信の際に、インタフェース層（インタフェースライブラリ３９の呼び出し）で指定される受信先スレッドのＩＤを、受信先のマイクロカーネル３０（プロセッサコア１１）に変換する処理を実行する。また、このメッセージマネージャ３４は、メッセージ受信の際に、受信したスレッド宛てのメッセージをスレッドに届ける処理を実行する。これらの処理の詳細については、後ほど説明する。
割り込みマネージャ３５（割り込み管理機能）は、プロセッサコア１１で発生した割り込みをハンドリングする機能である。

【0026】

インタフェースライブラリ３９は、オペレーティングシステムのサービスをシステムコールとして呼び出すためのものである。このインタフェースライブラリ３９は、例えばメッセージ送信用のＡＰＩやメッセージ受信用のＡＰＩを提供しており（後述）、これらのＡＰＩをスレッドから呼び出すことで、スレッドがメッセージの送受信機能を使用できるようにしている。

【0027】

なお、各マイクロカーネル３０は、自コアに割り当てられたスレッドに関する情報や、自コアに割り当てられたスレッド宛のメッセージを管理するための情報を保持している。具体的には、図２に示すように、メモリ２０にマイクロカーネル３０ごとにマイクロカーネル制御情報２６が記憶されている。このマイクロカーネル制御情報２６には、自コアに割り当てられたスレッドに固有のスレッドメッセージバッファ２５（後述）のアドレスや、当該スレッドメッセージバッファ２５内の未読メッセージを指し示すポインタなどの情報が含まれている。各マイクロカーネル３０は、自分のマイクロカーネル制御情報２６には自由にアクセスできるが、他のマイクロカーネル３０に係るマイクロカーネル制御情報２６にはアクセスすることはできない。

【0028】

各マイクロカーネル３０は、互いに独立して動作するが、メッセージ送受信モジュール４０を介してメッセージの送受信を行うことができる。言い換えれば、各マイクロカーネル３０は、メッセージ送受信モジュール４０を介してのみ、互いの状態を参照し、互いの状態に影響を与えることができる。このメッセージ送受信モジュール４０は、マイクロカーネル３０よりも更にハードウェアに近い層を構成するモジュールであり、すべてのマイクロカーネル制御情報２６を直接参照することが可能となっている。

【0029】

なお、各マイクロカーネル３０間でメッセージの送受信を行う際には、受信順を管理するために排他制御が必要となる。この排他制御はメッセージ送受信モジュール４０によって実行される。例えば、メッセージ送受信モジュール４０は、マイクロカーネル制御情報２６に対する排他的なアクセスを実現する。これにより、メッセージ送受信モジュール４０は、メッセージの受信順を管理している。一方、マイクロカーネル３０は、メッセージ送受信モジュール４０から順番に渡されるメッセージを処理していくだけであり、メッセージの受信順は管理していない。このように、メッセージの送受信の順序に係る排他制御は、メッセージ送受信モジュール４０によって一元的に管理されている。

【0030】

また、マイクロカーネル３０が、後述するスレッドメッセージバッファ２５にアクセスするとき（例えば、スレッドメッセージバッファ２５の空きを参照したり、スレッドメッセージバッファ２５のキューを操作したりするとき）には、スレッドメッセージバッファ２５を参照するための専用のモジュール（メッセージ送受信モジュール４０であってもよいし、メッセージ送受信モジュール４０とは別のモジュールであってもよい）を使用する。このモジュールがスレッドメッセージバッファ２５へのアクセスを排他制御する。

【0031】

（クラスタおよびスケジューリングについて）
本実施形態に係るオペレーティングシステムは、プロセッサコア１１の管理効率を高めるため、クラスタと呼ぶグルーピングの概念を使用している。クラスタは、複数のプロセッサコア１１をグループ化したものであり、各プロセッサコア１１は少なくともいずれかのクラスタに所属している。このクラスタをさらに上位のクラスタにグループ化して、クラスタを階層構造とすることも可能である。

【0032】

図１に示す例では、４つのクラスタ（スケジューリングクラスタ１５）を設け、それぞれのクラスタに１６個のプロセッサコア１１が含まれるようにグループ化している。また、この４つのスケジューリングクラスタ１５が１つの上位クラスタ（ハードウェアクラスタ１６）に所属している。

【0033】

各クラスタには、スレッドをいずれかのプロセッサコア１１に割り振るためのスレッドスケジューラ３２、３３が配置されている。このスレッドスケジューラ３２、３３は、マイクロカーネル３０の一部として実行される。

【0034】

スレッドスケジューラ３２は、サーバースレッドとして構築され、自身が管轄するスレッドとプロセッサコア１１の範囲で、所定のポリシーに従って、スレッドをどのプロセッサコア１１へ割り振るかを決定する。スレッドをプロセッサコア１１へ振り分けることをロードバランシングと呼び、どのようにスレッドをプロセッサコア１１へ振り分けるかを定義するポリシーをロードバランシングポリシーと呼ぶ。本実施形態においては、優先度の高いスレッドが複数のプロセッサコア１１にできるだけ均一に割り当てられるようにロードバランシングポリシーが設定されている。なお、ロードバランシングの具体的な処理としては、例えば特開２０１５－１６４０５２号に記載された処理を使用することができる。

【0035】

スレッドスケジューラ３２は負荷を分散する目的で、オペレーティングシステム内に複数インスタンスが存在することがある。スレッドスケジューラ３２が複数になると、スレッドスケジューラ３２間でロードバランスを取る必要性から、さらに上位のスレッドスケジューラ３３が置かれる。

【0036】

本実施形態においては、各スケジューリングクラスタ１５に１つずつスレッドスケジューラ３２が配置され、このスレッドスケジューラ３２がスケジューリングクラスタ１５内のどのプロセッサコア１１にスレッドを割り当てるかを決定するようになっている。また、ハードウェアクラスタ１６に１つの上位のスレッドスケジューラ３３が配置され、この上位のスレッドスケジューラ３３がハードウェアクラスタ１６内のどのスケジューリングクラスタ１５にスレッドを割り当てるかを決定するようになっている。

【0037】

なお、スレッドスケジューラ３２、３３は、プロセッサコア１１やクラスタを超えてスレッドを管理しなければならないため、どのプロセッサコア１１にどのスレッドが割り当てられているかを管理するスレッド管理機能を備えている。具体的には、スケジューリングクラスタ１５を管理するスレッドスケジューラ３２は、スケジューリングクラスタ１５内の全スレッドのコア配置を管理しており、最上位のスレッドスケジューラ３３は、オペレーティングシステム内の全スレッドのコア配置を管理している。このため、あるスレッドがどのプロセッサコア１１に配置されているかを知りたい場合は、スレッドスケジューラ３２に問い合わせればよい。もし、問い合わせを受けたスレッドスケジューラ３２が管理するクラスタにスレッドがない場合でも、当該スレッドスケジューラ３２が上位のスレッドスケジューラ３３に問い合わせるので、スレッドが配置されているプロセッサコア１１を解決することができる。

【0038】

このスレッドスケジューラ３２、３３は、プロセッサコア１１間の負荷の偏りに応じて、スレッドを実行するプロセッサコア１１の再割り当て（マイグレーション）を行う。例えば、優先度の高いスレッドが集中して実行されているプロセッサコア１１がある場合、一部のスレッドを他のプロセッサコア１１へと移動させることで、自動的に負荷の調整を行う。優先度ベースのロードバランシングポリシーが適用されている場合には、優先度の高いスレッドが複数のプロセッサコア１１にできるだけ均一に割り当てられるように再配置を行う。

【0039】

ただし、すべてのスレッドが上記したようなマイグレーションを起こすわけではなく、マイグレーションを起こさないスレッドも存在する。具体的には、スレッドの生成時にパラメータで動作コアを指定すると、このスレッドはコアアフィニティスレッドと呼ばれ、その後マイグレーションを起こさない。一方、生成時のパラメータで動作コアを指定しなかった場合は、このスレッドはマイグレーション可能スレッドと呼ばれ、その後マイグレーションする可能性がある。

【0040】

なお、すでに説明したように、スレッドスケジューラ３２、３３によってスレッドが割り振られた先のマイクロカーネル３０には、ローカルスケジューラ３１が存在している。ローカルスケジューラ３１は、自コアに割り振られたスレッドの中から実行するスレッドを選択し、ＲＵＮＮＩＮＧ状態とする。あるスレッドを選定し、これをＲＵＮＮＩＮＧ状態とすることをスケジューリングと呼び、これを決定するポリシーをスケジューリングポリシーと呼ぶ。本実施形態においては、自コアに割り振られたスレッドの中から、最も優先度の高いＲＥＡＤＹスレッドを選び、ＲＵＮＮＩＮＧ状態とする、優先度ベースのスケジューリングポリシーが適用されている。

【0041】

上記したように、本実施形態に係るオペレーティングシステムは、スレッドの実行権を制御するスケジューラとして、スレッドスケジューラ３２，３３とローカルスケジューラ３１との２種類を備え、この２つが相互に連動しながら動作する階層型スケジューラの構成となっている（図１参照）。具体的には、すべてのマイクロカーネル３０は、それぞれローカルスケジューラ３１が配置されている。そして、スケジューリングクラスタ１５内のいずれか１つのマイクロカーネル３０には、スレッドスケジューラ３２が配置されている。また、スケジューリングクラスタ１５よりも上位のクラスタ（例えばハードウェアクラスタ１６）がある場合、当該クラスタ内のいずれか１つのマイクロカーネル３０には、上位のスレッドスケジューラ３３が配置されている。

【0042】

なお、スレッドスケジューラ３２，３３は、サーバースレッドとして実行される。このため、スレッドスケジューラ３２，３３がメッセージの送受信を行う場合も、後述するメッセージ機能が使用される。例えば、あるスレッドがどのプロセッサコア１１に配置されているかについて、スレッドスケジューラ３２に問い合わせを行う場合にも、後述するメッセージ機能が使用される。

【0043】

（メッセージ機能の概要）
メッセージは、オペレーティングシステムによって提供されるスレッド間の通信手段である。メッセージは、最もハードウェアに近い下位層では、マイクロカーネル３０からマイクロカーネル３０へ送信されるが、上位のインタフェース層では、スレッドからスレッドに対して送信することが可能である。すなわち、ユーザプログラムがインタフェースライブラリ３９を使用してメッセージ送信を行う場合には、送信先にスレッドを指定して実行することが可能である。この場合、メッセージマネージャ３４によって、そのスレッドが割り当てられているマイクロカーネル３０が特定され、メッセージが伝達される。
なお、メッセージには「送信」と「受信」があり、また、送信と受信のそれぞれに「同期」と「非同期」がある。

【0044】

同期送信は、受信先スレッドがメッセージを受信するまで送信完了を待ち合わせる処理である。待ち合わせは、送信元スレッドをＷＡＩＴ状態とすることで実施される。一方、非同期送信は、受信先スレッドのメッセージ受信を待たずに送信を完了する処理である。

【0045】

また、同期受信は、メッセージを受信するまで受信完了を待ち合わせる処理である。待ち合わせは、受信先スレッドをＷＡＩＴ状態とすることで実施される。一方、非同期受信は、メッセージが送信済みの場合のみ受信を実施し、メッセージが送信済みでない場合はエラーとなる処理である。

【0046】

本オペレーティングシステムは、図３に示すように、メッセージ送信用のＡＰＩ（ｍｅｓｓａｇｅ＿ｓｅｎｄ）と、メッセージ受信用のＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｉｅｖｅ）を備えている。これらのＡＰＩをスレッドから呼び出すことで、スレッドがメッセージを送信したり、スレッドがメッセージを受信したりすることができる。

【0047】

メッセージ送信用のＡＰＩ（ｍｅｓｓａｇｅ＿ｓｅｎｄ）は、パラメータとして「送信先スレッドのＩＤ」「送信するデータの先頭アドレス」「送信するデータのサイズ」「同期／非同期のフラグ」を指定して実行する。

【0048】

なお、メッセージの送信には受信先のマイクロカーネル３０またはプロセッサコア１１を特定する必要があるが、これらはマイクロカーネル３０が内部的に解決するため、ＡＰＩのパラメータとして指定する必要はない。具体的には、メッセージマネージャ３４は、スレッドスケジューラ３２に問い合わせることで、受信先のマイクロカーネル３０やプロセッサコア１１を特定することができるようになっている。

【0049】

また、メッセージマネージャ３４は、受信先スレッドが所属するプロセッサコア１１を記憶するキャッシュ（Ｍｅｓｓａｇｅ Ｒｅｓｏｌｖｅｒ Ｃａｃｈｅ）を備えており、以前にメッセージを送信した際に解決したメッセージ受信先の内容を保持している。

【0050】

このため、メッセージ送信用のＡＰＩが呼び出されると、メッセージマネージャ３４は、まず受信先のスレッドが自コアに割り当てられているかをチェックする。自コアに割り当てられていれば、マイクロカーネル３０を探す必要はない。一方、自コアに割り当てられていない場合には、キャッシュを検索する。キャッシュにヒットした場合は、キャッシュの受信先を使用してメッセージを送信する。キャッシュミスした場合には、スレッドスケジューラ３２に問い合わせることで受信先を特定し、メッセージを送信するとともに、キャッシュの内容を更新する。

【0051】

また、メッセージ受信用のＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｉｅｖｅ）は、パラメータとして「データ格納領域の先頭アドレス」「データ格納領域のサイズ」「同期／非同期のフラグ」を指定して実行する。

【0052】

受信先のスレッドからｍｅｓｓａｇｅ＿ｒｅｃｉｅｖｅが呼び出されると、マイクロカーネル３０は、すでに受信済みメッセージを検索し、受信先のスレッドに宛てたものが存在するかをチェックする。メッセージが存在する場合は、ｍｅｓｓａｇｅ＿ｒｅｃｉｅｖｅのパラメータとして指定されたデータ格納領域に、メッセージをコピーして返却する。メッセージが存在しない場合、同期受信であればメッセージを受信するまで受信先のスレッドを待機させる。メッセージが存在せず、非同期受信の場合は、エラーを返却する。

【0053】

（メッセージのバッファ管理）
本実施形態に係るオペレーティングシステムは異なるマイクロカーネル３０に所属するスレッド間でメッセージングを行う際、メッセージバッファを介して行う。メッセージバッファは、ハードウェアクラスタ１６内の全てのプロセッサコア１１からアクセス可能となっている。メッセージバッファは各スレッドに固有のものがスレッドの生成時に確保される。このようなスレッドに固有のメッセージバッファをスレッドメッセージバッファ２５と呼ぶ。スレッドメッセージバッファ２５は、スレッドごとに作成されるため、スレッドと同じ数だけ確保されることになる。

【0054】

スレッドメッセージバッファ２５のサイズは、スレッド生成時のパラメータによって指定することができる。また、オペレーティングシステムのＡＰＩを使用することで、スレッド生成後にスレッドメッセージバッファ２５のサイズを変更することも可能である。スレッドメッセージバッファ２５のサイズは、受信可能な最大メッセージサイズと格納可能なメッセージ数を指定して、ユーザが任意に設定可能である。スレッドメッセージバッファ２５はキュー構造となっており、上記したメッセージ数だけメッセージを保存することができる。

【0055】

マイクロカーネル３０を介して送信したスレッド宛てのメッセージは、スレッドメッセージバッファ２５へ格納される。このスレッドメッセージバッファ２５へ格納されたメッセージは、受信側のマイクロカーネル３０の処理によって、ｍｅｓｓａｇｅ＿ｒｅｃｉｅｖｅのパラメータとして指定されたデータ格納領域にコピーされる。コピー後、スレッドメッセージバッファ２５に格納したメッセージは破棄される。
図３を参照しつつ、上記したスレッドメッセージバッファ２５を介したメッセージ送受信の流れを説明する。

【0056】

送信元スレッドから受信先スレッドＡにメッセージを送信する場合、送信元スレッドがｍｅｓｓａｇｅ＿ｓｅｎｄを呼び出す。このとき、受信先スレッドのＩＤには、受信先スレッドＡのＩＤを指定する。

【0057】

メッセージの送信要求（ｍｅｓｓａｇｅ＿ｓｅｎｄ）を受け取った送信元のマイクロカーネル３０は、受信先スレッドＡのＩＤを基に受信先のマイクロカーネル３０を特定する。具体的には、上記したように、キャッシュを検索するか、またはスレッドスケジューラ３２に問い合わせることで、受信先のマイクロカーネル３０を特定する。

【0058】

受信先のマイクロカーネル３０を特定したら、メッセージ送受信モジュール４０を使用して、メッセージをスレッドメッセージバッファ２５に書き込む。すなわち、メッセージ送受信モジュール４０は、受信先のマイクロカーネル３０のマイクロカーネル制御情報２６と受信先スレッドＡのＩＤとを基に、受信先スレッドＡに割り当てられたスレッドメッセージバッファ２５を特定する。そして、スレッドメッセージバッファ２５を特定出来たら、このバッファにメッセージを書き込む。なお、メッセージを書き込む際には、メッセージの書き込まれていない空きのキューを獲得して、そこに書き込む。空きのキューがない状態は、スレッドメッセージバッファ２５に空きがないため、メッセージ送信に失敗することになる（ｍｅｓｓａｇｅ＿ｓｅｎｄはエラーを返す）。書き込まれたメッセージは、マイクロカーネル制御情報２６において書き込み順に受信キューで管理されるため、受信先のマイクロカーネル３０は、書き込み順にメッセージを読み出せるようになっている。具体的には、上記した受信キューには、スレッドメッセージバッファ２５の先頭アドレスが、書き込み順につながれて格納されている。

【0059】

一方、受信先スレッドＡがメッセージを受信する場合、まず、メッセージを受け取るためのデータ格納領域を確保する。そして、このデータ格納領域の先頭アドレスとサイズをパラメータに指定して、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅを呼び出す。

【0060】

メッセージの受信要求（ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅ）を受け取った受信先のマイクロカーネル３０は、受信先スレッドＡ宛てのメッセージをすでに受信しているかをチェックする。具体的には、上記した受信キューを参照し、未読のメッセージがあるかを確認する。未読のメッセージがある場合には、受信キューに格納されたアドレスを基にスレッドメッセージバッファ２５に書き込まれたメッセージを読み込む。

【0061】

受信先スレッドＡ宛てのメッセージが存在する場合は、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅのパラメータで指定されたデータ格納領域にメッセージをコピーし、当該メッセージをスレッドメッセージバッファ２５から削除する。

【0062】

受信先スレッドＡ宛てのメッセージが存在せず、かつ、同期受信が指定されている場合は、受信先スレッドＡ宛てのメッセージが届くまで待機する。受信先スレッドＡ宛てのメッセージが届いたら、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅのパラメータで指定されたデータ格納領域にメッセージをコピーし、当該メッセージをスレッドメッセージバッファ２５から削除する。

【0063】

なお、上記した説明では、受信先スレッドＡにメッセージを送信しているが、受信先スレッドＢにメッセージを送信する場合でも、上記と同様の処理によりメッセージを送信することができる。このときには、受信先スレッドＢに割り当てられたスレッドメッセージバッファ２５を使用して、メッセージのやり取りが行われる。このように、受信先のスレッドごとに異なるスレッドメッセージバッファ２５を使用してメッセージングが行われる。 また、スレッドメッセージバッファ２５は特定のプロセッサコア１１に依存していないため、スレッドがマイグレーションした場合でも、スレッドメッセージバッファ２５は移動せずにそのまま使用することができる。ただし、当該スレッドを管理するマイクロカーネル３０が変わることになるため、マイクロカーネル制御情報２６の書き換えは必要となる。具体的には、スレッドがいなくなるマイクロカーネル３０に係るマイクロカーネル制御情報２６からは、当該スレッドに係る情報、例えば当該スレッドに割り当てられたスレッドメッセージバッファ２５のアドレス情報は削除される。そして、スレッドが追加されるマイクロカーネル３０に係るマイクロカーネル制御情報２６には、当該スレッドに係る情報、例えば当該スレッドに割り当てられたスレッドメッセージバッファ２５のアドレス情報が追加される。

【0064】

（メッセージ送信処理）
メッセージ送信処理の具体的な流れについて、図４のフローを参照しながら説明する。このメッセージ送信処理は、メッセージ送信用ＡＰＩ（ｍｅｓｓａｇｅ＿ｓｅｎｄ）が呼び出されたときに、送信元カーネル（送信元スレッドが属するマイクロカーネル３０）によって実行される処理である。図４のフローは、ｍｅｓｓａｇｅ＿ｓｅｎｄの内部で実行される処理を説明している。ただし、このフローでは、エラー処理などの一部の処理については説明を省略している。例えば、不正なパラメータが指定された場合には、ｍｅｓｓａｇｅ＿ｓｅｎｄの戻り値としてエラー値を返却するが、このような処理については説明を省略している。

【0065】

まず、図４に示すステップＳ１０５において、任意の送信元スレッドがメッセージ送信用ＡＰＩ（ｍｅｓｓａｇｅ＿ｓｅｎｄ）を呼び出す。このＡＰＩ呼び出しを送信元カーネルが受け取ることによって、メッセージ送信処理が開始される。そして、ステップＳ１１０に進む。

【0066】

ステップＳ１１０では、受信先スレッドが同一プロセッサコア１１に割り当てられているかがチェックされる。具体的には、ｍｅｓｓａｇｅ＿ｓｅｎｄで指定された受信先スレッドのＩＤを基にマイクロカーネル制御情報２６を参照し、受信先スレッドを送信元カーネルが制御しているかがチェックされる。受信先スレッドが同一プロセッサコア１１に割り当てられている場合は、ステップＳ１６０に進む。また、受信先スレッドが同一プロセッサコア１１に割り当てられていない場合は、ステップＳ１１５に進む。

【0067】

ステップＳ１６０に進んだ場合、送信元スレッドと受信先スレッドとが同じプロセッサコア１１に割り当てられており、同じマイクロカーネル３０によって制御されているため、スレッドメッセージバッファ２５を介することなく受信先スレッドにメッセージを渡すことができる。具体的には、受信先スレッドがすでに受信待ち状態であれば、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅで指定されたデータ格納領域にメッセージをコピーする。また、受信先スレッドが受信待ち状態でなければ、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅが呼び出されたときに、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅで指定されたデータ格納領域にメッセージをコピーする。このとき、ｍｅｓｓａｇｅ＿ｓｅｎｄが非同期で実行されていれば、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅが呼び出されるのを待たずにｍｅｓｓａｇｅ＿ｓｅｎｄを終了し、送信元スレッドへと処理を返却する。以上でメッセージ送信処理が終了する。

【0068】

一方、ステップＳ１１５に進んだ場合、以前にメッセージを送信した際に解決したメッセージ受信先のキャッシュ（Ｍｅｓｓａｇｅ Ｒｅｓｏｌｖｅｒ Ｃａｃｈｅ）を検索し、受信先スレッドの所属の解決を試みる。キャッシュに受信先スレッドが見つかった場合は、受信先スレッドが属するマイクロカーネル３０（受信先カーネル）を特定し、ステップＳ１３５へ進む。一方、キャッシュに受信先スレッドが見つからなかった場合には、ステップＳ１２０に進む。

【0069】

ステップＳ１２０では、スレッドスケジューラ３２に問い合わせを行う前処理として、メッセージを送信元スレッドのスレッドメッセージバッファ２５にコピーして退避させる。この処理は、メッセージを格納している領域が、スレッドスケジューラ３２に問い合わせを行っている間に書き換えられることを防止するためである。そして、ステップＳ１２５に進む。

【0070】

ステップＳ１２５では、受信先スレッドのＩＤを基に、スレッドスケジューラ３２（スレッド管理機能）に問い合わせを行い、受信先カーネルを特定するための情報（例えば、受信先カーネルのＩＤまたはプロセッサコア１１のＩＤ）を取得する。この問い合わせ自体も、スレッドメッセージバッファ２５を使用したメッセージ送信（後述するステップＳ１４５～ステップＳ１５０を参照）により実行される（ただし、送信元カーネルにスレッドスケジューラ３２が配置されている場合は、スレッドメッセージバッファ２５を使用したメッセージ送受信は不要である）。問い合わせを受けたスレッドスケジューラ３２は、必要に応じて上位のスレッドスケジューラ３３にさらに問い合わせを行い、受信先カーネルを特定する。受信先カーネルを特定したら、スレッドスケジューラ３２は、スレッドメッセージバッファ２５を使用したメッセージ送信によって、受信先カーネルを特定するための情報を送信元カーネルに渡す。そして、ステップＳ１３０に進む。

【0071】

ステップＳ１３０では、ステップＳ１２５で解決した受信先スレッドと受信先カーネルの情報を、キャッシュ（Ｍｅｓｓａｇｅ Ｒｅｓｏｌｖｅｒ Ｃａｃｈｅ）に登録する。例えば、受信先スレッドのＩＤと受信先カーネルのＩＤ（またはプロセッサコア１１のＩＤ）とを紐付けたデータを、メモリ２０に記憶させる。そして、ステップＳ１３５に進む。

【0072】

ステップＳ１３５では、受信先カーネルに係る情報（ＩＤなど）を指定してメッセージ送受信モジュール４０を呼び出し、メッセージ送信を行う。メッセージ送受信モジュール４０は、受信先カーネルに係る情報（ＩＤなど）が判明しているので、この情報を基に受信先カーネルのマイクロカーネル制御情報２６を参照する。受信先カーネルのマイクロカーネル制御情報２６には、受信先カーネルが管理するスレッドのスレッドメッセージバッファ２５のアドレスが記憶されている。よって、受信先カーネルが管理するマイクロカーネル制御情報２６と受信先スレッドのＩＤとを基に、受信先スレッドに割り当てられたスレッドメッセージバッファ２５（送信先バッファ）のアドレスを取得することができる。そして、ステップＳ１４０に進む。

【0073】

ステップＳ１４０では、ステップＳ１３５の処理において送信先バッファを特定できたかをチェックする。すなわち、ステップＳ１１５でＹＥＳとなったものの、キャッシュに登録されている情報が古い場合（キャッシュに登録された後でスレッドマイグレーションが発生していた場合）、キャッシュの情報を基に特定した受信先カーネルに受信先スレッドが存在せず、送信先バッファを特定できない場合がある。このような場合は、ステップＳ１２０に戻り、スレッドスケジューラ３２への問い合わせを行う。一方、送信先バッファを特定できた場合は、ステップＳ１４５に進む。

【0074】

ステップＳ１４５では、メッセージ送受信モジュール４０が、送信先バッファにメッセージを書き込む（コピーする）。このとき、受信先カーネルのマイクロカーネル制御情報２６を書き換えて、メッセージが書き込まれたことが分かるようにしておく。なお、もしこのときに送信先バッファが不足してあふれてしまう場合は、メッセージ送信は失敗する。このため、重要なメッセージを受信するスレッドのスレッドメッセージバッファ２５は、枯渇しないように十分な余裕をもって確保すべきである。そして、ステップＳ１５０に進む。

【0075】

ステップＳ１５０では、メッセージ送受信モジュール４０が、受信先カーネルに対応するプロセッサコア１１に割り込みを発生させ、受信先カーネルに書き込み（ステップＳ１４５）の終了を通知する。このＣＰＵ割り込みは、受信先カーネルの割り込みハンドラによって処理されるため、受信先カーネルは割り込みによって書き込み（ステップＳ１４５）があったことを検知することができる。そして、ステップＳ１５５に進む。

【0076】

ステップＳ１５５は、同期制御の場合にのみ実行される処理である。このステップＳ１５５では、受信先カーネルからの受信完了通知がメッセージにより通知されることを待機する。受信先カーネルから受信完了通知を受け取ったら、メッセージ送信処理を終了し、ｍｅｓｓａｇｅ＿ｓｅｎｄの呼び出し元へと処理を返す。なお、非同期制御の場合には、受信先カーネルからの受信完了通知を待つことなく、メッセージ送信処理を終了し、ｍｅｓｓａｇｅ＿ｓｅｎｄの呼び出し元へと処理を返す（ただし、非同期実行かつステップＳ１２５が行われた場合には、その時点でｍｅｓｓａｇｅ＿ｓｅｎｄの呼び出し元へと処理を返される。この場合は、ステップＳ１５５ではｍｅｓｓａｇｅ＿ｓｅｎｄの呼び出し元に処理を返さない）。

【0077】

（割り込み発生時のメッセージ受信処理）
次に、割り込み発生時のメッセージ受信処理の具体的な流れについて、図５のフローを参照しながら説明する。このメッセージ受信処理は、上記したメッセージ送信処理のステップＳ１５０において発生した割り込みを検知したときに、受信先カーネル（受信先スレッドが属するマイクロカーネル３０）の割り込みハンドラによって実行される処理である。

【0078】

まず、図５に示すステップＳ２０５において、メッセージの書き込み完了を通知するＣＰＵ割り込みが発生する。このＣＰＵ割り込みによって、受信先カーネルの割り込みハンドラが起動し、メッセージ受信処理が開始される。そして、ステップＳ２１０に進む。

【0079】

ステップＳ２１０では、メッセージ送受信モジュール４０が、受信先カーネルのマイクロカーネル制御情報２６を参照し、未取り出しのメッセージを特定する。未取り出しのメッセージが複数ある場合は、所定のポリシー（メッセージの到達順、メッセージの優先度順、など）に従って、順番にメッセージを処理する。なお、マイクロカーネル制御情報２６には、メッセージを格納したスレッドメッセージバッファ２５のアドレスが記憶されているだけであり、実際のメッセージはスレッドメッセージバッファ２５に記憶されている。そして、ステップＳ２１０に進む。

【0080】

ステップＳ２２０では、メッセージ送受信モジュール４０が、受信先カーネル（メッセージマネージャ３４）に、読み出し対象のメッセージを示すスレッドメッセージバッファ２５のポインタを渡す。受信先カーネルは、スレッドメッセージバッファ２５の中身を参照し、メッセージを読み込む。メッセージのヘッダには、メッセージの宛先（例えば受信先スレッドのＩＤ）が記載されている。これを参照し、受信先スレッドを特定する。そして、ステップＳ２２５に進む。

【0081】

ステップＳ２２５では、受信先スレッドが受信待ちであるかがチェックされる。具体的には、受信先スレッドが同期制御を指定してメッセージ受信用ＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅ）を呼び出しており、ＷＡＩＴ状態となっているかがチェックされる。受信待ちでない場合は、ステップＳ２３０に進む。受信待ちの場合は、ステップＳ２３５に進む。

【0082】

ステップＳ２３０では、受信待ちメッセージキューにメッセージ（のポインタ）を追加する。受信待ちメッセージキューは、スレッドの受け取りを待っている受信メッセージをスレッドごとに管理するためのキューである。受信先スレッドがｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅを呼び出してメッセージを受け取るまで、受信先スレッドの受信待ちメッセージキューに当該メッセージが保持されることになる。そして、割り込み処理を終了する。

【0083】

ステップＳ２３５に進んだ場合、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅのパラメータとして指定されたデータ格納領域に、スレッドメッセージバッファ２５の内容をコピーする。そして、ステップＳ２４０に進む。

【0084】

ステップＳ２４０では、メッセージをスレッドメッセージバッファ２５から削除する（本実施形態においては、キュー構造で管理されているスレッドメッセージバッファ２５について、当該メッセージが格納されていた領域を、空きバッファとしてキューに戻す処理を行う）。また、読み出したメッセージを取り出し済みとするために、自身（受信先カーネル）のマイクロカーネル制御情報２６を書き換える。そして、ステップＳ２４５に進む。

【0085】

ステップＳ２４５では、受信先スレッドのＷＡＩＴ状態を解除する。これにより、受信先スレッドにおいて、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの呼び出し元へと処理が返される。そして、割り込み処理を終了する。

【0086】

（ＡＰＩ呼び出し時のメッセージ受信処理）
次に、ＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅ）呼び出し時のメッセージ受信処理の具体的な流れについて、図６のフローを参照しながら説明する。このメッセージ受信処理は、メッセージ受信用ＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅ）が呼び出されたときに、受信先カーネル（受信先スレッドが属するマイクロカーネル３０）によって実行される処理である。図６のフローは、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの内部で実行される処理を説明している。ただし、このフローでは、エラー処理などの一部の処理については説明を省略している。例えば、不正なパラメータが指定された場合には、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの戻り値としてエラー値を返却するが、このような処理については説明を省略している。

【0087】

まず、図６に示すステップＳ３０５において、任意の受信先スレッドがメッセージ受信用ＡＰＩ（ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅ）を呼び出す。このＡＰＩ呼び出しを受信先カーネルが受け取ることによって、処理が開始される。そして、ステップＳ３１０に進む。

【0088】

ステップＳ３１０では、受信待ちメッセージキューにメッセージがあるか（図５のステップＳ２３０で追加されたメッセージがあるか）がチェックされる。メッセージがある場合は、ステップＳ３１５に進む。メッセージがない場合は、ステップＳ３３０に進む。

【0089】

ステップＳ３１５に進んだ場合、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅのパラメータとして指定されたデータ格納領域に、スレッドメッセージバッファ２５の内容をコピーする。そして、ステップＳ３２０に進む。

【0090】

ステップＳ３２０では、メッセージをスレッドメッセージバッファ２５から削除する（上記したように、メッセージが格納されていた領域を、空きバッファとしてスレッドメッセージバッファ２５のキューに戻す処理を行う）。また、読み出したメッセージを取り出し済みとするために、自身（受信先カーネル）のマイクロカーネル制御情報２６を書き換える。以上でメッセージ受信処理が完了したので、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの呼び出し元へと処理を返す。

【0091】

また、ステップＳ３３０に進んだ場合、同期受信であるかがチェックされる。同期受信の場合は、ステップＳ３３５に進む。非同期受信の場合は、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの呼び出し元へとエラーを返し、処理を終了する。

【0092】

ステップＳ３３５では、受信先スレッドをＷＡＩＴ状態に設定する。これにより、受信先スレッドは、図５のステップＳ２４５でＷＡＩＴ状態を解除するまで待機することになる。ＷＡＩＴ状態を解除されたら、処理を終了し、ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅの呼び出し元へと処理を返す。

【0093】

（まとめ）
上記したように、本実施形態によれば、スレッドの生成時に、当該スレッドに固有のスレッドメッセージバッファ２５が確保されている。このため、高い安全性が求められないスレッドに対するメッセージが一時的に増加してバッファが枯渇した場合でも、高い安全性が求められるスレッドが影響を受けることはない。このため、メッセージの受信量が一時的に増加した場合でも、重要なメッセージを確実に送受信することができる。

【0094】

また、スレッドメッセージバッファ２５を確保するにあたり、スレッドごとに使用する最大サイズを見積もり、スレッドごとに任意のサイズを設定することができる。スレッドが使用するバッファのサイズは、スレッドがマイグレーションしても変わらないので、必要なバッファサイズの計算も容易である。

【0095】

例えば、あるスレッドが必要とするバッファサイズは「１メッセージ当たりの格納可能最大サイズ×格納可能なメッセージ数」で求めることができる。高い安全性が求められるスレッドについては、十分なバッファを確保することで、仮にほかのスレッドのバッファがあふれてしまった場合でも、影響なくメッセージを受信することができる。

【符号の説明】

【0096】

１０ ＣＰＵ
１１ プロセッサコア
１５ スケジューリングクラスタ
１６ ハードウェアクラスタ
２０ メモリ
２５ スレッドメッセージバッファ
２６ マイクロカーネル制御情報
３０ マイクロカーネル
３１ ローカルスケジューラ
３２ スレッドスケジューラ（スレッド管理機能）
３３ 上位のスレッドスケジューラ
３４ メッセージマネージャ
３５ 割り込みマネージャ
３９ インタフェースライブラリ
４０ メッセージ送受信モジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】