JP7346649B2 - 同期制御システムおよび同期制御方法 - Google Patents

Description

この発明は、複数のプロセッサコアを搭載したコンピュータ上で実行される同期制御システムおよび同期制御方法に関する。

スレッド間の同期制御方法として、従来型のオペレーティングシステムにおいては、排他制御を伴う共有メモリ参照方式が用いられていた。例えば、特許文献１に記載の発明では、共有メモリを用いて通信を行うとともに、複数のプロセッサから共有メモリにアクセスする際の排他制御のためにセマフォ（排他制御用変数）を用いている。このような構成においては、セマフォを獲得したあとに共有メモリへアクセスし、読み出し又は書き込みを行うことにより、複数のプロセッサからの同時アクセスを禁止し、同時書き込みによるデータ破壊やデータ読み出し中にデータが書き換えられることを防止している。このため、セマフォ獲得失敗時にはポーリングやスピンロックなどでセマフォ解放を待つ必要がある。このような共有メモリ参照方式では、競合発生時のＣＰＵ負荷や排他制御時のバス負荷が大きくなる傾向があり、システム性能に与えるインパクトが大きかった。

この点、共有メモリを参照するのではなく、メッセージングにより通信を行うようにすれば、システム全体の高い並列実行性能を実現することができる。例えば、イベント待ちを管理するサーバスレッドをオペレーティングシステムの一部として設け、このサーバスレッドに対してメッセージングを行うことで同期を行うようにすれば、ポーリングやスピンロックを使用せずに通信を行うことができる。ただし、メッセージングそのものの実行時間は、共有メモリ参照方式よりも大きくなる傾向があり、スレッド間の同期や通信が多用される環境では遅延時間の影響が大きくなる可能性があった。

特開２０１７－１４６７０３号公報

そこで、本発明は、最低限のメッセージング回数でスレッド間の同期を制御することができる同期制御システムおよび同期制御方法を提供することを課題とする。

上記した課題を解決するため、第１の発明は、複数のプロセッサコアを搭載したコンピュータ上で実行され、前記複数のプロセッサコアごとにスレッドのスケジューリングを行うマイクロカーネルを配置した同期制御システムであって、異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを備え、前記ロックオブジェクトは、前記複数のプロセッサコアごとに１つずつの、次に起床されるべきスレッドのスレッド情報を格納可能であり、任意のスレッドが前記ロックオブジェクトを解放するときに、当該ロックオブジェクトに格納されたスレッド情報から所定の待ち解除ポリシーに従って起床するスレッドを決定した後に、前記任意のスレッドを管理するマイクロカーネルから前記起床するスレッドを管理するマイクロカーネルへ待ち解除のメッセージを直接送信する。

また、第２の発明は、複数のプロセッサコアを搭載したコンピュータ上で、前記複数のプロセッサコアごとにスレッドのスケジューリングを行うマイクロカーネルを配置して実行される同期制御方法であって、異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを生成するステップと、前記ロックオブジェクトによりスレッドが待ち状態となったときに、前記ロックオブジェクトに当該スレッドのスレッド情報を登録するステップと、任意のスレッドが前記ロックオブジェクトを解放するときに、当該ロックオブジェクトに格納されたスレッド情報から所定の待ち解除ポリシーに従って起床するスレッドを決定した後に、前記任意のスレッドを管理するマイクロカーネルから前記起床するスレッドを管理するマイクロカーネルへ待ち解除のメッセージを直接送信するステップと、を備え、前記ロックオブジェクトには、前記複数のプロセッサコアごとに１つずつの、次に起床されるべきスレッドのスレッド情報を格納可能である。

本発明は上記の通りであり、最低限のメッセージング回数でスレッド間の同期を制御することができる。

コンピュータシステムの概略を示すブロック図である。 ロックオブジェクトの定義を示す図である。 待ち要求処理のフロー図である。 待ち解除要求送信処理のフロー図である。 待ち解除要求受信処理のフロー図である。 待ち要求の処理の流れを示すシーケンス図である。 待ち解除要求の処理の流れを示すシーケンス図である。

本発明の実施形態について、図を参照しながら説明する。
本実施形態に係るコンピュータシステムは、図１に示すようなコンピュータを備えている。このコンピュータは、ＣＰＵ１０と、主記憶装置１４と、補助記憶装置（図示せず）と、を備えている。

本実施形態に係るＣＰＵ１０は、１つのプロセッサパッケージ内に複数のプロセッサコア１１を搭載したマルチコア・プロセッサであり、例えば、第１プロセッサコア１１ａおよび第２プロセッサコア１１ｂの２つのプロセッサコア１１を備えている。なお、本実施形態においては、ＣＰＵ１０が第１プロセッサコア１１ａおよび第２プロセッサコア１１ｂの２つのプロセッサコア１１を備えている例について説明するが、これに限らず、ＣＰＵ１０は３つ以上のプロセッサコア１１を備えていてもよい。

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

オペレーティングシステム２０は、ＣＰＵ１０上でのスレッド３０の実行を制御するソフトウェアである。本実施形態に係るオペレーティングシステム２０は、上記した複数のプロセッサコア１１のそれぞれに対応して、複数のマイクロカーネル２１が実行されるように構成されている。マイクロカーネル２１は、オペレーティングシステム２０の核となるものであり、メモリ管理、割り込み要求処理、スレッド間通信などの必要最小限の機能を搭載したカーネルプログラムである。このマイクロカーネル２１は、システム起動時にプロセッサコア１１ごとにインスタンスが生成され、対応するプロセッサコア１１上で常に実行されるようになっている。

以下の説明においては、第１プロセッサコア１１ａ上で実行されるマイクロカーネル２１のインスタンスを第１マイクロカーネル２１ａと呼び、第２プロセッサコア１１ｂ上で実行されるマイクロカーネル２１のインスタンスを第２マイクロカーネル２１ｂと呼ぶこととする。また、記載を簡略化するため、マイクロカーネル２１のインスタンスを単にマイクロカーネル２１と記載する場合もある。なお、ＣＰＵ１０が３つ以上のプロセッサコア１１を備えている場合には、プロセッサコア１１の数と同数のマイクロカーネル２１のインスタンスが生成され、それぞれのプロセッサコア１１で１つのマイクロカーネル２１が実行されることになる。

これらのマイクロカーネル２１は、他のマイクロカーネル２１と通信を行うためのメッセージング機能を有している。マイクロカーネル２１が、このメッセージング機能を使用して相互に通信を行うことで、異なるプロセッサコア１１または同一のプロセッサコア１１に割り当てられたスレッド３０間での同期を実現する同期制御システムが実現されている。この同期制御システムについては後ほど詳述する。

また、これらのマイクロカーネル２１は、当該マイクロカーネル２１が実行されるプロセッサコア１１（以下、マイクロカーネル２１それ自体が実行されるプロセッサコア１１のことを、当該マイクロカーネル２１の「自コア」という）に割り当てられたスレッド３０のスケジューリングを行う。すなわち、マイクロカーネル２１は、予め定められた所定のスケジューリングポリシーに従って、自コアで実行するスレッド３０を選択し、スレッド３０を順番に実行する。なお、スケジューリングポリシーとして何を選択するかは任意に設定可能である。例えば、スレッド３０の優先度順、ラウンドロビン方式、ＦＩＦＯなどの既知のスケジューリングポリシーのうちから最適なものを使用すればよい。

マイクロカーネル２１によるスケジューリングは、具体的には、スレッド３０の状態を遷移させることにより行われる。このスレッド３０の状態としては、少なくとも、「実行状態」「実行可能状態」「待ち状態」がある。「実行状態」は、スレッド３０にプロセッサコア１１が割り当てられて実行している状態である。また、「実行可能状態」は、プロセッサコア１１が割り当てられれば実行できるが、他のスレッド３０がプロセッサコア１１を占有しているため、実行を待機している状態である。また、「待ち状態」は、何らかのイベントが完了するのを待っている状態である。

例えば、スレッド３０は以下のように状態が遷移する。まず、生成されたスレッド３０は、実行可能状態になり、マイクロカーネル２１が管理する実行可能状態のキューに接続される。このキューで最も高い優先順位にあるスレッド３０は、マイクロカーネル２１によってディスパッチされ、実行可能状態から実行状態に遷移する。なお、スレッド３０の実行中に、割込みにより他のスレッド３０に実行権が渡されると、実行中のスレッド３０は実行可能状態に遷移する。また、同期処理などの特定のイベントが発生した場合には、マイクロカーネル２１によってスレッド３０が待ち状態に遷移する。待ち状態に遷移したスレッド３０は、待ち状態が解除されるまで待機し、待ち状態が解除されたら実行可能状態に遷移する。

なお、スレッド３０が生成されると、当該スレッド３０を制御するためにスレッド制御ブロックが生成される。このスレッド制御ブロックは、スレッド３０ごとに１つ生成され、スレッド３０が終了するまでマイクロカーネル２１によって管理される。このスレッド制御ブロックには、上記したスレッド３０の状態や、スレッド３０の優先度などの情報が登録される。本実施形態においては、このスレッド制御ブロックに、後述する待ち管理キューも登録される。

本実施形態に係るスレッド３０は、基本的に生成されたプロセッサコア１１上で実行される。このため、生成されたプロセッサコア１１上で実行しているマイクロカーネル２１によって制御されることになる。例えば、図１に示すように、第１グループ３１で実行されるスレッド３０は、第１プロセッサコア１１ａ上で第１マイクロカーネル２１ａによって制御されて実行される。また、第２グループ３２で実行されるスレッド３０は、第２プロセッサコア１１ｂ上で第２マイクロカーネル２１ｂによって制御されて実行される。このとき、第１グループ３１で実行されるスレッド３０と第２グループ３２で実行されるスレッド３０とは、互いに直接通信を行うことはできないため、別のグループのスレッド３０間で通信を行う場合には、共有メモリ１５またはマイクロカーネル２１を介して通信を行う必要がある。

共有メモリ１５は、すべてのプロセッサコア１１で共有されるメモリ領域である。この共有メモリ１５へは、どのプロセッサコア１１で実行しているスレッド３０であってもアクセス可能である。本実施形態においては、この共有メモリ１５に、複数のロックオブジェクト３５を生成可能である。

ロックオブジェクト３５は、異なるプロセッサコア１１または同一のプロセッサコア１１に割り当てられたスレッド３０間での同期処理を実行するための共有資源である。このロックオブジェクト３５は、共有メモリ１５に生成されるため、割り当てられたプロセッサコア１１にかかわらずすべてのスレッド３０がアクセス可能となっている。また、このロックオブジェクト３５はユーザ空間に生成されるため、空きメモリが存在する限りにおいて無制限に生成可能である。

本実施形態に係るロックオブジェクト３５は、図２に示すような構造体で定義される（構造体名「ｌｏｃｋｏｂｊ」で定義される構造体を参照）。このロックオブジェクト３５は、メンバとして、複数のプロセッサコア１１数分の配列であるスレッド情報格納配列（ｐｅｒｃｐｕ［ＣＯＲＥ＿ＣＯＵＮＴ］；ＣＯＲＥ＿ＣＯＵＮＴはプロセッサコア１１の数を示す定数）を含んでいる。

本実施形態に係るスレッド情報格納配列の各要素は、任意のスレッド３０に係るスレッド情報である。このスレッド情報は、図２に示すような構造体で定義される（構造体名「ｌｏｃｋｉｎｆｏ」で定義される構造体を参照）。このスレッド情報は、メンバとして「ｔｉｄ」と「ｐｒｉ」とを含んでいる。また、「ｕｉｎｔ１６＿ｔ」は、これらメンバのデータ型が１６ビットの符号なし整数型であることを示している。なお、「ｔｉｄ」には、任意のスレッド３０を特定するためのスレッド識別子が格納される。また、「ｐｒｉ」には、当該スレッド識別子で特定されるスレッド３０の優先度が格納される。

このように、本実施形態に係るスレッド情報（構造体「ｌｏｃｋｉｎｆｏ」）は、メンバとしてスレッド識別子とスレッド優先度とを含んでいる。このスレッド識別子とスレッド優先度とは、アトミックに（一体不可分に）読み書きされる必要がある。このため、このスレッド識別子とスレッド優先度とは、ＣＰＵ１０がアトミックに操作できるサイズとなっている。具体的には、構造体「ｌｏｃｋｉｎｆｏ」のサイズ（スレッド識別子とスレッド優先度とを足したサイズ）が、ＣＰＵ１０のビット数（ＣＰＵ１０が不可分操作可能な最大ビット数）を超えないように設定されている。本実施形態に係るＣＰＵ１０は３２ｂｉｔであるため、スレッド識別子とスレッド優先度とを足したサイズ（本実施形態においては、スレッド識別子もスレッド優先度も１６ｂｉｔの変数であるため、これらを足したサイズは３２ｂｉｔである）が、３２ｂｉｔを超えないように設定されている。このように構成することで、スレッド情報にアクセスする際に排他制御が不要となっている。

なお、上記した図２においては、Ｃ言語における構造を例に説明しているが、Ｃ言語以外のプログラミング言語であっても、上記したロックオブジェクト３５と同様の構造を定義することにより、プログラミング言語に依存せずに同様の効果を得ることができる。構造体の記述方法も、プログラミング言語に応じて変更可能である。

上記したスレッド情報格納配列には、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド情報が格納される。例えば、プロセッサコア１１が２つの場合には、ｐｅｒｃｐｕ［］の要素数は「２」であり、ｐｅｒｃｐｕ［０］には第１プロセッサコア１１ａにおいて次に起床されるべきスレッド３０に係るスレッド情報が格納され、ｐｅｒｃｐｕ［１］には第２プロセッサコア１１ｂにおいて次に起床されるべきスレッド３０に係るスレッド情報が格納される。なお、プロセッサコア１１が３つ以上の場合も同様に、ｐｅｒｃｐｕ［］の要素数をプロセッサコア１１の数に合わせて設定し、ｐｅｒｃｐｕ［］の各要素に１つずつプロセッサコア１１を割り当てて、当該ｐｅｒｃｐｕ［
］の要素に当該プロセッサコア１１において次に起床されるべきスレッド３０に係るスレッド情報を格納すればよい。

これにより、ロックオブジェクト３５には、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド識別子が格納されるようになっている。なお、本実施形態に係るスレッド情報格納配列を構造体「ｌｏｃｋｉｎｆｏ」の配列としたが、これに限らず、ロックオブジェクト３５は少なくとも複数のプロセッサコア１１ごとにスレッド識別子を格納できるものであればよい。例えば、スレッド情報格納配列を数値型の配列として、スレッド識別子のみを格納するようにしてもよい。その他、構造体「ｌｏｃｋｉｎｆｏ」のメンバを図２で示す定義から変更してもよい。

上記したロックオブジェクト３５は、同期を必要とするイベントごとに動的に生成可能である。例えば、ロックオブジェクト３５をラップする排他制御用の上位オブジェクト（ミューテックスなど）のインスタンス生成時に合わせて生成することができる。

本実施形態に係る同期制御システムは、このロックオブジェクト３５を使用して、異なるプロセッサコア１１または同一のプロセッサコア１１で実行されているスレッド３０間で同期制御を行うことができる。

すなわち、特定のスレッド３０が、ロックオブジェクト３５を使用した資源待ちとなると、当該ロックオブジェクト３５のスレッド情報格納配列に、待ち状態となったスレッド３０のスレッド識別子が格納される。このとき、スレッド情報格納配列のどの要素に格納されるかは、スレッド３０を実行しているプロセッサコア１１に依存する。すなわち、スレッド３０を実行しているプロセッサコア１１に割り当てられたスレッド情報格納配列の要素に、待ち状態となったスレッド３０のスレッド情報が格納される。

一方、このようにロックオブジェクト３５により待ち状態となったスレッド３０の待ち状態の解除を行うときには、当該ロックオブジェクト３５を検索して、スレッド情報格納配列に格納されたスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッド３０を実行可能状態に移行させる。

以下、上記した同期制御に係る処理フローについて詳しく説明する。なお、本実施形態の同期制御に係る処理フローは、大きく分けて、（１）待ち要求処理、（２）待ち解除要求送信処理、（３）待ち解除要求受信処理、の３つの処理からなるため、以下それぞれについて説明する。

（待ち要求処理）
待ち要求処理は、イベントの終了待ちを行うスレッド３０からの要求を受けて、当該スレッド３０を制御するマイクロカーネル２１（当該スレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。この待ち要求処理について、図３に示すフローを参照しながら説明する。

まず、図３に示すステップＳ１００において、マイクロカーネル２１が、任意のスレッド３０（以下、「待ち要求スレッド」という）から待ち要求を受信する。具体的には、待ち要求スレッドが、ロックオブジェクト３５を指定したＡＰＩ呼び出し（後述するｍｆｕｔｅｘ＿ｗａｉｔ（））を行ったときに、マイクロカーネル２１による待ち要求処理が開始される。そして、ステップＳ１０５に進む。

ステップＳ１０５では、ステップＳ１００で指定されたロックオブジェクト３５のスレッド情報格納配列を参照し、自コアに対応して格納されたスレッド情報に含まれるスレッド識別子（以下、「格納済ＩＤ」という）を取得する。そして、ステップＳ１１０に進む。

ステップＳ１１０では、格納済ＩＤが有効であるか無効であるかがチェックされる。スレッド情報格納配列にすでにスレッド情報が格納されている場合には格納済ＩＤが有効であるが、スレッド情報格納配列にスレッド情報が格納されていない場合（自コアにおいて、当該ロックオブジェクト３５を使用した待ちスレッド３０が存在しない場合）には格納済ＩＤが無効である。格納済ＩＤが無効である場合（またはスレッド情報格納配列にスレッド情報が格納されていない場合）には、ステップＳ１１５へ進む。一方、格納済ＩＤが有効である場合（すなわちスレッド情報格納配列にスレッド情報が格納されている場合）には、ステップＳ１２０に進む。

ステップＳ１１５に進んだ場合、自コアにおいて当該ロックオブジェクト３５により待ち状態となったスレッド３０群を管理するための待ち管理キューを生成し、この待ち管理キューを、待ち要求スレッドに係るスレッド制御ブロックに登録する。また、この待ち管理キューに、待ち要求スレッドに係るスレッド制御ブロックを挿入する。これにより、待ち要求スレッドと待ち管理キューとが相互にリンクされる。そして、ステップＳ１２５に進む。

ステップＳ１２０に進んだ場合、格納済みＩＤで特定されるスレッド３０に係るスレッド制御ブロックを参照し、当該スレッド制御ブロックに登録された待ち管理キューを取得する。そして、この待ち管理キューを、待ち要求スレッドに係るスレッド制御ブロックに登録する。また、この待ち管理キューに、当該スレッド制御ブロックを挿入する。これにより、待ち要求スレッドと待ち管理キューとが相互にリンクされる。そして、ステップＳ１２５に進む。

ステップＳ１２５では、待ち管理キューを検索し、次に起床されるべきスレッド３０（待ち管理キューに登録されたスレッド３０の中で最も先に起床されるべきスレッド３０）を取得する。次に起床されるべきスレッド３０は、所定の待ち解除ポリシーに従って決定される。待ち解除ポリシーとしてどのようなポリシーを使用するかは任意であるが、本実施形態においては、スレッド３０の優先度順に待ち解除を行うようにしている。すなわち、待ち管理キューに登録されたすべてのスレッド制御ブロックを検索し、最も優先度の高いスレッド３０を選択する。そして、ステップＳ１３０に進む。

なお、待ち解除ポリシーとしては、スレッド３０の優先度順に限らず、別のポリシーを設定することも可能である。例えば、ＦＩＦＯ（先入れ先出し方式）を使用してもよいし、特定の属性を有するスレッド３０（例えば、書き込みロックを獲得しているライター・スレッド３０）を優先的に待ち解除するようにしてもよい。

ステップＳ１３０では、ステップＳ１２５で取得した、次に起床されるべきスレッド３０のスレッド情報（スレッド識別子およびスレッド優先度）を、ロックオブジェクト３５のスレッド情報格納配列（自コアに対応するスレッド情報格納配列の要素）に格納する。なお、ステップＳ１２５で取得したスレッド情報がすでにスレッド情報格納配列に格納されている場合には、スレッド情報格納配列の書き換えを行う必要はない。そして、ステップＳ１３５に進む。

ステップＳ１３５では、待ち要求スレッドを「待ち状態」に移行させる。これにより、待ち要求スレッドは、待ち状態が解除されるまで実行されることはない。以上で、処理が終了する。

（待ち解除要求送信処理）
待ち解除要求送信処理は、同期に係るイベントを終了したスレッド３０からの要求を受けて、当該スレッド３０を制御するマイクロカーネル２１（当該スレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。すなわち、ロックオブジェクト３５を解放して、次のスレッド３０に実行権を明け渡すべく実行される処理である。この待ち解除要求送信処理について、図４に示すフローを参照しながら説明する。

まず、図４に示すステップＳ２００において、マイクロカーネル２１が、任意のスレッド３０（以下、「待ち解除スレッド」という）から待ち要求を受信する。この待ち要求においては、起床するスレッド３０（実行権の明け渡し先のスレッド３０）のスレッド識別子と、ロックオブジェクト３５と、が指定されている。具体的には、待ち解除スレッドが、起床するスレッド３０のスレッド識別子とロックオブジェクト３５とを指定したＡＰＩ呼び出し（後述するｍｆｕｔｅｘ＿ｗａｋｅ（ｔｉｄ，ｌｏｃｋｏｂｊ））を行ったときに、マイクロカーネル２１により待ち解除要求処理が開始される。そして、ステップＳ２０５に進む。

ステップＳ２０５では、ステップＳ２００で取得したスレッド識別子を基に（例えば、ステップＳ２００で取得したスレッド識別子と、ロックオブジェクト３５のスレッド情報格納配列の要素とを比較し）、起床するスレッド３０を実行中のプロセッサコア１１を特定する。そして、当該プロセッサコア１１に係るスレッド３０群を管理するマイクロカーネル２１に対し、待ち解除のメッセージを送信する。本実施形態に係るオペレーティングシステム２０は、複数のプロセッサコア１１ごとに配置されたマイクロカーネル２１間でのメッセージング機能を備えており、このメッセージング機能によって、待ち解除のメッセージが送信される。

メッセージが送信されると、メッセージ送信先のマイクロカーネル２１によって、後述する待ち解除要求受信処理が実行される。メッセージが受け入れられて、待ち解除要求送信処理が開始されると、送信先から回答が来るため、この回答を受け取って処理が終了する。なお、送信先においてメッセージが受け入れられなかった場合（起床するスレッド３０がロックオブジェクト３５を待機していない場合）、送信先は失敗情報とともに回答を送信する。この場合は、ロックオブジェクト３５を再度スキャンして、別の適切なターゲット（起床するスレッド３０）を決定し、待ち解除のメッセージを送信することになる。

（待ち解除要求受信処理）
待ち解除要求受信処理は、上記した待ち解除のメッセージを受信したマイクロカーネル２１（起床するスレッド３０が実行されているプロセッサコア１１に割り当てられたマイクロカーネル２１）によって実行される処理である。この待ち解除要求受信処理について、図５に示すフローを参照しながら説明する。
まず、図５に示すステップＳ３００において、マイクロカーネル２１が、上記した待ち解除のメッセージを受信する。そして、ステップＳ３０５に進む。

ステップＳ３０５では、起床するスレッド３０を待ち管理キューから除外する。すなわち、起床するスレッド３０に係るスレッド制御ブロックに登録された待ち管理キューを取得し、当該待ち管理キューから、起床するスレッド３０に係るスレッド制御ブロックを削除する。待ち管理キューは、共通のロックオブジェクト３５に起因して待機している複数のスレッド３０群（同じプロセッサコア１１で実行されているスレッド３０群）で共有されているため、これらのスレッド３０群に係るスレッド制御ブロックに登録された待ち管理キューからも、起床するスレッド３０に係るスレッド制御ブロックが削除されることになる。そして、ステップＳ３１０に進む。

ステップＳ３１０では、ステップＳ３０５で取得した待ち管理キューを検索し、今回起床するスレッド３０の次に起床されるべきスレッド３０に係るスレッド制御ブロックを選択する。このとき、次に起床されるべきスレッド３０は、図３のステップＳ１２５と同様に、所定の待ち解除ポリシーに従って決定される。そして、ステップＳ３１５に進む。

ステップＳ３１５では、ステップＳ３１０で選択した、次に起床されるべきスレッド３０に係るスレッド情報（スレッド識別子およびスレッド優先度）を、ロックオブジェクト３５のスレッド情報格納配列（自コアに対応するスレッド情報格納配列の要素）に格納する。なお、ステップＳ３１０において、待ち管理キューにスレッド３０が存在しなかった場合には、自コアに対応するスレッド情報格納配列の要素に、無効なスレッド情報（または、無効なスレッド識別子を含むスレッド情報）を格納する。そして、ステップＳ３２０に進む。
ステップＳ３２０では、起床するスレッド３０のステータスを「実行可能状態」に移行する。そして、ステップＳ３２５に進む。
ステップＳ３２５では、起床するスレッド３０をディスパッチし、「実行状態」に移行させる。以上で、処理が終了する。

（待ち要求処理のシーケンス）
次に、上記した待ち要求処理において、スレッド３０およびマイクロカーネル２１間でどのようなやり取りが発生するのかを、図６に示すシーケンス図を用いて説明する。この図６では、スレッドＡが、何らかのイベント待ちとなる様子を示している。例えば、スレッドＡが、ミューテックスの獲得に失敗して待ち状態となる場合などである。

スレッドＡがミューテックスの獲得に失敗すると、そのミューテックスの下位オブジェクトであるロックオブジェクト３５を使用して待ち要求が発行される。本実施形態に係る待ち要求は、ｍｆｕｔｅｘ＿ｗａｉｔ（）という、オペレーティングシステム２０のＡＰＩ（システムコール）として設けられている。ｍｆｕｔｅｘ＿ｗａｉｔ（）では、引数としてロックオブジェクト３５が渡される。

ｍｆｕｔｅｘ＿ｗａｉｔ（）が呼び出されると、スレッドＡを管理するマイクロカーネル２１（ここでは第１マイクロカーネル２１ａ）による処理が開始される。第１マイクロカーネル２１ａは、図３で説明したように、ロックオブジェクト３５を参照して、ロックオブジェクト３５の解放を待っている自コアのスレッド３０が既に存在するか否かをチェックする。そして、そのチェック結果に応じて、ロックオブジェクト３５や待ち管理キューの内容を適切に書き換える。そして、スレッドＡを「待ち状態」に移行させる。

（待ち要求解除処理のシーケンス）
次に、上記した待ち解除要求送信処理および待ち解除要求受信処理において、スレッド３０およびマイクロカーネル２１間でどのようなやり取りが発生するのかを、図７に示すシーケンス図を用いて説明する。この図７では、ロックオブジェクト３５に係る実行権が、第２プロセッサコア１１ｂで実行中のスレッドＢから、第１プロセッサコア１１ａで実行中のスレッドＡへと受け渡される様子を示している。例えば、スレッドＢがミューテックスを解放したことにより、スレッドＡがミューテックスを獲得する場合などである。

スレッドＢがミューテックスを解放したときには、まず、実行権を受け渡す先のスレッド３０を決定する。本実施形態に係る待ち解除ポリシーは、スレッド３０の優先度順であるため、ミューテックスの下位オブジェクトであるロックオブジェクト３５のスレッド情報格納配列を検索し、最も優先度の高いスレッド３０のスレッド識別子を取得する（スレッド情報格納配列に格納されたスレッド情報のスレッド優先度をすべてチェックし、最も優先度の高いスレッド情報に係るスレッド識別子を取得する）。そして、そのスレッド識別子とロックオブジェクト３５とを使用して、待ち解除要求を発行する。本実施形態に係る待ち解除要求は、ｍｆｕｔｅｘ＿ｗａｋｅ（）という、オペレーティングシステム２０のＡＰＩ（システムコール）として設けられている。このｍｆｕｔｅｘ＿ｗａｋｅ（）は、引数として、スレッド識別子とロックオブジェクト３５とを指定するようになっている。

ｍｆｕｔｅｘ＿ｗａｋｅ（）が呼び出されると、スレッドＢを管理するマイクロカーネル２１（ここでは第２マイクロカーネル２１ｂ）による処理が開始される。第２マイクロカーネル２１ｂは、図４で説明したように、実行権を受け渡す先のスレッド３０（ここではスレッドＡ）を管理するマイクロカーネル２１（ここでは第１マイクロカーネル２１ａ）に対し、待ち解除のメッセージを送信する。このメッセージングは、例えば、待ち解除のメッセージであることを示す識別子（図７では、ＭＦＵＴＥＸ＿ＷＡＫＥで定義された定数）、起床するスレッド３０のスレッド識別子、ロックオブジェクト３５を指定して実行される。

このメッセージを第１マイクロカーネル２１ａが受信すると、図５で説明したように、ロックオブジェクト３５や待ち管理キューの登録内容を適切に書き換える。そして、スレッドＡを「実行可能状態」に移行させる。その後、所定のスケジューリングポリシーに従い、スレッドＡをディスパッチしたときに、スレッドＡが第１マイクロカーネル２１ａによって実行される。

なお、上記の説明では、ロックオブジェクト３５に係る実行権が、第２プロセッサコア１１ｂで実行中のスレッドＢから、第１プロセッサコア１１ａで実行中のスレッドＡへと受け渡される例について説明した。すなわち、異なるプロセッサコア１１に割り当てられたスレッド３０間での同期処理について説明した。しかしながら、これに限らず、ロックオブジェクト３５に係る実行権が、同じプロセッサコア１１内で受け渡されるようにしてもよい。すなわち、同一のプロセッサコア１１に割り当てられたスレッド３０間で同期処理を行うようにしてもよい（例えば、図７に示すスレッドＡとスレッドＢとが同じプロセッサコア１１内で実行されていてもよい）。

（まとめ）
本実施形態は上記の通りであり、割り当てられたプロセッサコア１１にかかわらずすべてのスレッド３０がアクセス可能な共有資源のロックオブジェクト３５を備え、このロックオブジェクト３５は、複数のプロセッサコア１１ごとに、次に起床されるべきスレッド３０のスレッド識別子を格納可能である。そして、ロックオブジェクト３５により待ち状態となったスレッド３０の待ち状態の解除を行うときには、当該ロックオブジェクト３５を検索して次に起床する待ち状態のスレッド３０のスレッド識別子を取得し、当該スレッド識別子を使用したメッセージングによりスレッド３０を実行可能状態に移行させるようにしている。このため、最低限のメッセージング回数でスレッド３０間の同期を制御することができる。

また、このような態様によれば、共有メモリ参照方式と比較して以下の優位性がある。すなわち、共有メモリ参照方式においては、複数のプロセッサコア１１から共有メモリ１５にアクセスする際の排他制御においてセマフォやミューテックスの獲得失敗時にはポーリングやスピンロックなどでオブジェクトの解放を待つ必要がある。しかしながら、本発明によれば、メッセージングにより同期制御を行うため、ポーリングやスピンロックを使用せずに同期制御を行うことができる。よって、競合発生時に無駄なＣＰＵリソースを消費することがなく、また、排他制御時のバス負荷も低下させることができる。

また、このような態様によれば、従来のメッセージングによる同期制御と比較して以下の優位性がある。すなわち、従来のメッセージングによる同期制御においては、サーバスレッドを介して同期制御を行うため、サーバスレッドを経由する分だけメッセージング回数が増加し、また、サーバスレッドを設けることで資源が消費されていた。この点、本実施形態によれば、共有資源のロックオブジェクト３５を使用することで、サーバスレッドを介さずに同期制御を実行することができる。よって、メッセージング回数を減少させ、スレッド資源を節約することができる。また、ロックオブジェクト３５がユーザ空間に配置されるため、サーバスレッドの静的なコンフィギュレーションに依存せず、空きメモリが存在する限りは無制限でロックオブジェクト３５を生成することができる。すなわち、ロックオブジェクト３５を使用した同期制御のイベント数について、実質的に制限がない。

また、従来の排他制御として、グローバルロックを使用してすべてのプロセッサコア１１が同じクリティカルセクションに入ることができないように制御するものがある。しかしながら、本実施形態によれば、ロックを解除するスレッド３０とロックを獲得しているスレッド３０によって使用されるプロセッサコア１１のみが排他制御にかかわるため、排他制御にかかわらないプロセッサコア１１の処理能力を低下させることがない。

なお、上記した実施形態においては、待ち解除ポリシーとしてスレッド３０の優先度順を用いているため、スレッド情報格納配列にスレッド３０の優先度を格納した。しかしながら、待ち解除ポリシーとしてスレッド３０の優先度順を用いない場合には、スレッド情報格納配列にスレッド３０の優先度を格納する必要はない。例えば、待ち解除ポリシーとしてＦＩＦＯ（先入れ先出し方式）を用いる場合、スレッド情報格納配列には最低限の情報としてスレッド識別子が格納されていればよい。そして、待ち管理キューの先頭のスレッド３０に係るスレッド識別子をスレッド情報格納配列に格納すればよい。また、どのプロセッサコア１１に係るスレッド３０の待ち解除を行うのかについても、任意のルールを設定可能である。例えば、配列を順番に参照するようにした場合、待ち解除要求を送信するプロセッサコア１１に係るスレッド情報格納配列の添字がｎ（ｎは、ｎ＜ＣＯＲＥ＿ＣＯＵＮＴを満たす非負整数）である場合、スレッド情報格納配列の添字がｍ（ｍは、ｎ＋１＝ＣＯＲＥ＿ＣＯＵＮＴのときには「０」、それ以外のときには「ｎ＋１」）のプロセッサコア１１に係るスレッド３０に待ち解除要求を送信するようにしてもよい。

１０ ＣＰＵ
１１ プロセッサコア
１１ａ 第１プロセッサコア
１１ｂ 第２プロセッサコア
１４ 主記憶装置
１５ 共有メモリ
２０ オペレーティングシステム
２１ マイクロカーネル
２１ａ 第１マイクロカーネル
２１ｂ 第２マイクロカーネル
３０ スレッド
３１ 第１グループ
３２ 第２グループ
３５ ロックオブジェクト

Claims (12)

1. 複数のプロセッサコアを搭載したコンピュータ上で実行され、前記複数のプロセッサコアごとにスレッドのスケジューリングを行うマイクロカーネルを配置した同期制御システムであって、
   異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを備え、
   前記ロックオブジェクトは、前記複数のプロセッサコアごとに１つずつの、次に起床されるべきスレッドを特定可能な識別子を含むスレッド情報を格納可能であり、
   任意のスレッドが前記ロックオブジェクトを解放するときに、当該ロックオブジェクトに格納されたスレッド情報から所定の待ち解除ポリシーに従って起床するスレッドを決定した後に、前記任意のスレッドを管理するマイクロカーネルから前記起床するスレッドを管理するマイクロカーネルへ待ち解除のメッセージを直接送信する、同期制御システム。
2. 前記ロックオブジェクトは、前記複数のプロセッサコア数分の配列であるスレッド情報格納配列を含み、
   前記スレッド情報格納配列に、前記スレッド情報を格納する、請求項１記載の同期制御システム。
3. 前記スレッド情報格納配列の各要素のサイズは、ＣＰＵが不可分操作可能な最大ビット数を超えないように設定されている、請求項２記載の同期制御システム。
4. スレッドを制御するためにスレッドごとに生成されるスレッド制御ブロックを備え、
   前記ロックオブジェクトにより待ち状態となったスレッドに係る前記スレッド制御ブロックには、同じロックオブジェクトにより待ち状態となったスレッド群を管理するための待ち管理キューが登録される、請求項１～３のいずれか１項に記載の同期制御システム。
5. 前記メッセージは、オペレーティングが備えるメッセージング機能を使用して送信される、請求項１～４のいずれか１項に記載の同期制御システム。
6. 前記ロックオブジェクトは、同期を必要とするイベントごとに動的に生成可能である、請求項１～５のいずれか１項に記載の同期制御システム。
7. 複数のプロセッサコアを搭載したコンピュータ上で、前記複数のプロセッサコアごとにスレッドのスケジューリングを行うマイクロカーネルを配置して実行される同期制御方法であって、
   異なるプロセッサコアまたは同一のプロセッサコアに割り当てられたスレッド間での同期処理を実行するための共有資源であり、割り当てられた前記プロセッサコアにかかわらずすべてのスレッドがアクセス可能なロックオブジェクトを生成するステップと、
   前記ロックオブジェクトによりスレッドが待ち状態となったときに、前記ロックオブジェクトに当該スレッドを特定可能な識別子を含むスレッド情報を登録するステップと、
   任意のスレッドが前記ロックオブジェクトを解放するときに、当該ロックオブジェクトに格納されたスレッド情報から所定の待ち解除ポリシーに従って起床するスレッドを決定した後に、前記任意のスレッドを管理するマイクロカーネルから前記起床するスレッドを管理するマイクロカーネルへ待ち解除のメッセージを直接送信するステップと、
   を備え、
   前記ロックオブジェクトには、前記複数のプロセッサコアごとに１つずつの、次に起床されるべきスレッドのスレッド情報を格納可能である、同期制御方法。
8. 前記ロックオブジェクトは、前記複数のプロセッサコア数分の配列であるスレッド情報格納配列を含み、
   前記ロックオブジェクトによりスレッドが待ち状態となったときに、当該スレッドが実行されているプロセッサコアの番号に対応した前記スレッド情報格納配列の要素に当該スレッドのスレッド情報を格納する、請求項７記載の同期制御方法。
9. 前記スレッド情報格納配列の各要素のサイズは、ＣＰＵのビット数を超えないように設定されている、請求項８記載の同期制御方法。
10. スレッドを制御するためにスレッドごとに生成されるスレッド制御ブロックを備え、
    前記ロックオブジェクトによりスレッドが待ち状態となったときに、当該スレッドに係る前記スレッド制御ブロックに、同じロックオブジェクトにより待ち状態となったスレッド群を管理するための待ち管理キューが登録される、請求項７～９のいずれか１項に記載の同期制御方法。
11. 前記メッセージは、オペレーティングが備えるメッセージング機能を使用して送信される、請求項７～１０のいずれか１項に記載の同期制御方法。
12. 前記ロックオブジェクトは、同期を必要とするイベントごとに動的に生成可能である、請求項７～１１のいずれか１項に記載の同期制御方法。

Images