(57)【要約】【課題】マルチコアプロセッサ向けのリアルタイムシステムの安全性を確保すると共に、プロセッサコアを効率良く利用する。【解決手段】マルチコアプロセッサにより構成されたリアルタイムシステムにおいて、スレッドにより共有されうる各共有リソースのシーリング値に基づいたプライオリティ・シーリング方式で、スレッドによる共有リソースの操作時の排他制御を行うと共に、同一のシーリング値を有する共有リソースが同一のグループになるように共有リソースをグループ分けして得たグループ単位のセマフォ方式でスレッドのスケジューリングを行う。【選択図】図４
2010020683.tif 000002
【特許請求の範囲】
【請求項１】
複数のプロセッサコアと、複数のスレッドにより共有されうる複数のリソースとを備えたリアルタイムシステムにおけるスレッド制御方法において、
各前記リソースのシーリング値に基づいたプライオリティ・シーリング方式で、スレッドによるリソース操作時の排他制御を行い、
同一のシーリング値を有するリソースが同一のグループになるように前記複数のリソースをグループ分けし、グループ単位のセマフォ方式でスレッドのスケジューリングを行うことを特徴とするスレッド制御方法。
【請求項２】
同一のグループ内のリソースのうちの、同様の１つ以上のスレッドにより操作される可能性のあるリソースから構成されたセットであって、かつ、該セットに対応する前記１つ以上のスレッドが前記グループ内の前記セット以外のいずれのリソースも操作する可能性が無い前記セットに含まれるリソースを別グループにさらに分けることを特徴とする請求項１に記載のスレッド制御方法。
【請求項３】
複数のプロセッサコアと、複数のスレッドにより共有されうる複数のリソースとを備えたリアルタイムシステムにおけるスレッド制御装置であって、
各前記リソースのシーリング値に基づいたプライオリティ・シーリング方式で、スレッドによるリソース操作時の排他制御を行い、
同一のシーリング値を有するリソースが同一のグループになるように前記複数のリソースをグループ分けして得たグループ単位のセマフォ方式でスレッドのスケジューリングを行う制御部を備えることを特徴とするスレッド制御装置。
【請求項４】
同一のグループ内のリソースのうちの、同様の１つ以上のスレッドにより操作される可能性のあるリソースから構成されたセットであって、かつ、該セットに対応する前記１つ以上のスレッドが前記グループ内の前記セット以外のいずれのリソースも操作する可能性が無い前記セットに含まれるリソースは、別グループにさらに分けられていることを特徴とする請求項３に記載のスレッド制御装置。
【請求項５】
複数のプロセッサコアと、
複数のスレッドにより共有されうる複数のリソースと、
各前記リソースのシーリング値に基づいたプライオリティ・シーリング方式で、スレッドによる前記リソースの操作時の排他制御を行い、同一のシーリング値を有するリソースが同一のグループになるように前記複数のリソースをグループ分けして得たグループ単位のセマフォ方式でスレッドのスケジューリングを行う制御部とを備えることを特徴とするリアルタイムシステム。
【請求項６】
同一のグループ内のリソースのうちの、同様の１つ以上のスレッドにより操作される可能性のあるリソースから構成されたセットであって、かつ、該セットに対応する前記１つ以上のスレッドが前記グループ内の前記セット以外のいずれのリソースも操作する可能性が無い前記セットに含まれるリソースは、別グループにさらに分けられていることを特徴とする請求項５に記載のリアルタイムシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スレッド制御、特にマルチコアプロセッサ向けのリアルタイムシステムにおけるスレッドの実行制御に関する。
【背景技術】
【０００２】
リアルタイムシステムで実行される逐次処理の単位は「スレッド」または「タスク」などの呼称があり、本明細書においては、「スレッド」と呼ぶ。多くのリアルタイムＯＳ（オペレーティングシステム）は、リアルタイム性を確保するためのスケジューリングポリシとしてプリエンプティブな優先度ベースのスケジューリングをサポートする。このスケジューリングポリシは、下記のように定められている。
【０００３】
１．その時点で最も高い優先度のスレッドが実行される。
２．その時点で最も高い優先度のスレッドの処理は中断されてはいけない。
３．同一優先度の場合は先着順とする。「先着順」は、スレッドが実行可能状態に遷移した順番を意味する。
４．優先度の高いスレッドが実行可能状態になった場合、該スレッドより優先度が低いスレッドの処理の途中であっても、スレッドの切替えを行って高い優先度のスレッドを実行させる。
【０００４】
上述した「実行可能状態」は、プリエンプトされた他のスレッドが無いとき、またはプリエンプトされた他のスレッドがＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の実行権を解放すれば実行できる状態を意味する。
【０００５】
図１１は、優先度が「高」であるスレッドＨ１、優先度が「中」であるスレッドＭ１とスレッドＭ２、優先度が「低」であるスレッドＬ１が存在する場合に、これらのスレッドの実行順の例を示す。図示のように、優先度の高い順からスレッドが実行され、同一優先度のスレッドＭ１とスレッドＭ２については、先に実行可能状態になったスレッドＭ１が実行される。
【０００６】
以下において、スレッドの表記に「Ｈ」、「Ｍ」、「Ｌ」を付けることにより当該スレッドの優先度が「高」、「中」、「低」であることを示す。
【０００７】
リアルタイムシステムにおいて、共有リソースの衝突問題を解決するために、共有リソースの排他処理（以下単に排他処理という）が行われる。図１２は、この排他処理の模式図である。
【０００８】
図１２に示すように、あるスレッドは、共有リソースを操作するのに当たって、まず、ＯＳに対してしてリソース獲得要求（以下単に獲得要求ともいう）を発行する。そして、リソース獲得要求に応じてＯＳから共有リソースの操作が許可されれば、共有リソースを操作し、操作完了後、リソース解放要求（以下単に解放要求ともいう）をＯＳに発行する。ＯＳは、他のスレッドにより共有リソースが操作されていないことを条件に、リソース獲得要求を発行したスレッドにリソース操作を許可する。これにより、複数のスレッドが同時に共有リソースを操作することを回避することができる。なお、スレッドが共有リソースを獲得してから、共有リソースを解放するまでの期間は、「排他処理期間」または「ブロック期間」という。
【０００９】
共有リソースの衝突問題を簡単に解決できる排他処理機構として、多くのリアルタイムＯＳにはセマフォが装備されている。セマフォには、非負整数をとるカウンティングセマフォ、「０」と「１」をとるバイナリ・セマフォがあり、以下バイナリ・セマフォを例に説明する。なお、共有リソースを操作するような、排他処理が必要な区間をクリティカルリージョンという。
【００１０】
セマフォを使用する上では、下記の約束事が定められている。
１．スレッドがクリティカルリージョンに入るときにセマフォをとる。
２．セマフォがない間は、他のスレッドはクリティカルリージョンに入れない。
３．セマフォが他のスレッドにとられているときはセマフォが戻るまで待つ。
４．クリティカルリージョンから出るときにセマフォを戻す。
５．スレッドをとる間は不可分に（スレッドが切り替わることがなく）実行される。
６．セマフォを戻す間も不可分に実行される。
７．セマフォを戻すときに待っているスレッドがあればそのスレッドの待ち状態を解除すする。
【００１１】
図１３は、セマフォを用いたリアルタイムシステムにおけるスレッドの実行模式を示す。図中において、実行中のスレッドＭ１は、獲得要求をＯＳに発行してセマフォを取得してリソースの操作をする。その後、スレッドＭ１が解放要求をＯＳに発行してセマフォを戻すまでは、ブロック期間であり、この期間において他のスレッドがセマフォをとることができない。図１３に示すように、時刻ｔ０において、優先度が「高」であるスレッドＨ１が実行可能状態に遷移したため、スレッドＭ１の実行が中断され、スレッドＨ１が実行される。時刻ｔ１において、スレッドＨ１が獲得要求を発行するものの、セマフォがスレッドＭ１に所有されているため、スレッドＨ１が中断され、スレッドＭ１が再開される。のちに、スレッドＭ１がセマフォを解放すると、スレッドＨ１は、やっとセマフォを取得する。これに伴って、スレッドＨ１が実行され、スレッドＭ１が中断される。
【００１２】
以下、スレッドがセマフォを待つことを「排他待ち」といい、図１３に示す時刻ｔ０〜時刻ｔ１のような、排他待ちをしている区間を「排他待ち期間」という。
【００１３】
セマフォを利用した場合の問題点として、優先度逆転とデッドロックが挙げられる。図１４と図１５を参照して説明する。
【００１４】
図１４は、優先度逆転のケースを説明するための図である。このケースでは、まず、優先度が「低」であるスレッドＬ１はセマフォを取得して共有リソースを操作する。スレッドＬ１による共有リソースの操作中に、優先度が「高」であるスレッドＨ１が実行可能状態に遷移したため、スレッドＬ１の実行が中断され、スレッドＨ１が実行される。時刻ｔ０において、スレッドＨ１が獲得要求を発行してセマフォを取得しようとするが、セマフォがスレッドＬ１により所有されているため、スレッドＨ１は実行が中断され、排他待ち期間に入る。これに伴い、スレッドＬ１の実行は再開される。
【００１５】
時刻ｔ１において、優先度が「中」であるスレッドＭ１が実行可能状態に遷移したため、スレッドＬ１は再び中断され、スレッドＭ１は実行される。そして、スレッドＭ１の実行が完了した時刻ｔ２において、スレッドＬ１の実行は再開される。その後、スレッドＬ１がセマフォを戻して共有リソースを解放したときに、スレッドＨ１はセマフォを取得して、やっと実行される。
【００１６】
このように、時刻ｔ１〜ｔ２の区間において、スレッドＨ１がスレッドＭ１より優先度が高いにもかかわらず、スレッドＭ１が先に実行されるという「優先度逆転」が起きてしまう。
【００１７】
図１５は、デットロックのケースを説明するための図である。デッドロックは共有リソースが複数ある場合に生じうる。図１５の例に示すように、まず、スレッドＭ１は共有リソースであるリソースＡのセマフォを取得してリソースＡを操作する。時刻ｔ０において、スレッドＨ１が実行可能状態に遷移したため、スレッドＨ１は実行され、スレッドＭ１は中断される。そして、時刻ｔ１において、スレッドＨ１は別の共有リソースであるリソースＢのセマフォを取得して、リソースＢを操作する。処理が進み、時刻ｔ２において、スレッドＨ１は、リソースＡを操作するためにリソースＡのセマフォを要求するが、リソースＡのセマフォはスレッドＭ１により所有されているため、スレッドＨ１は中断され、排他待ち期間に入る。そこで、スレッドＭ１は、実行が再開される。
【００１８】
処理がさらに進み、スレッドＭ１はリソースＢを操作するためにリソースＢのセマフォを要求するが、リソースＢのセマフォはスレッドＨ１により所有されているため、スレッドＭ１も中断され、排他待ち期間に入る。
【００１９】
こうなると、スレッドＨ１とスレッドＭ１のいずれも実行することができず、いわゆるデットロックが発生する。
【００２０】
セマフォを利用する際に生じる優先度逆転とデットロックの問題を解決するために、特許文献１にも記載されたように、セマフォを取得したスレッドの優先度を一時的に高くするプライオリティ・シーリング方式を用いた手法がある。
【００２１】
プライオリティ・シーリング方式は、スレッドがリソースのセマフォを取得すると、直ちにこのスレッドの優先度を該リソースのシーリング値に一時的に上げる方式である。図１６を参照して説明する。なお、シーリング値は、当該リソースを獲得する可能性のあるすべてのスレッドの優先度以上の優先度であり、予め設定されている。また、スレッドは、自身の優先度（優先度が一時的に挙げられているときには、そのときの優先度）より低いシーリング値を有するリソースを取得できないように規定されている。
【００２２】
図１６の例において、まず、スレッドＬ１はセマフォを取得して共有リソースを操作する。スレッドＬ１によるセマフォの取得と同時に、その優先度は「低」から、該リソースのシーリング値（例えば「高」）に変更される。そのため、スレッドＬ１がセマフォを解放するまでの間、スレッドＭ１とスレッドＨ１が実行状態に遷移しても、スレッドＬ１は続行される。
【００２３】
スレッドＬ１はセマフォを解放すると、その優先度が元の「低」に戻される。そのため、最も優先度の高いスレッドＨ１は実行され、スレッドＬ１は中断される。
【００２４】
スレッドＨ１は、処理を続き、共有リソースを操作するためにセマフォを要求し、セマフォを取得する。スレッドＨ１がセマフォを解放した後も処理を続き、処理を完了した時（時刻ｔ０）に、スレッドＭ１は実行される。そして、スレッドＭ１が処理を完了したとき（時刻ｔ１）に、スレッドＬ１は再開される。
【００２５】
このように、プライオリティ・シーリング方式は、優先度が高いスレッドの実行中に、その優先度より低い優先度を有するスレッドが実行されないことを利用して、セマフォを取得したスレッドの優先度をシーリング値に一時的に変更し、該スレッドによる共有リソースの操作を優先的に実行させることより、前述した優先度逆転の問題を回避することができる。
また、同じ理由で、共有リソースが複数ある場合のデットロックの問題も発生しない。
【特許文献１】特表２００５−５１６２８１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２６】
ここで、マルチコアプロセッサ向けのリアルタイムシステムについて考える。このようなシステムでは、複数のスレッドが同時に実行可能であるため、高い処理効率を得ることができる。その一方、共有リソースの競合問題も同様に存在し、それを解決する排他処理機構を設ける必要がある。
【００２７】
マルチコアプロセッサ向けのリアルタイムシステムの排他処理機構にプライオリティ・シーリング方式を適用しても、デットロックの問題が生じうる。図１７を参照して説明する。
【００２８】
図１７において、縦軸が優先度を示す。プロセッサコアとしてプロセッサコアＡとプロセッサコアＢの２つがあり、共有リソースとしてリソースＡとリソースＢの２つがあるとする。また、リソースＡとリソースＢのいずれも、シーリング値は「高」である。
【００２９】
図１７の例では、まず、プロセッサコアＡで実行中のスレッドＬ１は、リソースＡを操作するためにリソースＡのセマフォを取得する。これにより、スレッドＬ１の優先度がリソースＡのシーリング値「高」に一時的に変更される。
【００３０】
優先度「高」で動作するスレッドＬ１によるリソースＡの操作中に、スレッドＭ１が実行可能状態に遷移する。このとき、プロセッサコアＢが空いているので、スレッドＭ１はプロセッサコアＢで実行される。そして、スレッドＭ１は、リソースＢを操作するためにリソースＢのセマフォを取得する。これにより、スレッドＭ１の優先度がリソースＢのシーリング値の「高」に一時的に変更される。
【００３１】
処理が続き、リソースＡの操作中のスレッドＬ１はさらにリソースＢのセマフォ取得要求を発行する。このとき、リソースＢのセマフォがスレッドＭ１により所有されているため、スレッドＬ１は、実行が中断され、排他待ちする。
【００３２】
その後、リソースＢの操作中のスレッドＭ１はさらにリソースＡのセマフォ取得要求を発行する。リソースＡのセマフォがスレッドＬ１により所有されているので、スレッドＭ１も実行が中断され、排他待ちする。
こうなると、スレッドＨ１とスレッドＭ１のいずれも実行することができず、デットロックが発生する。
【００３３】
このように、マルチコアプロセッサによるリアルタイムシステムにおいて、優先度が異なる複数のスレッドが同時に動作可能であるため、優先度の高いスレッドの実行中に優先度の低いスレッドが実行されないことを利用したプライオリティ・シーリング方式を適用してもデッドロックが生じ得る。
【００３４】
この問題を回避するために、排他処理にプライオリティ・シーリング方式を適用すると共に、スレッドのスケジューリングに際して、実行可能状態にあるスレッドのうちの、優先度が最も高いスレッドのみをスケジューリング対象とする手法が考えられる。図１８を参照して説明する。
【００３５】
優先度が最も高いスレッドのみが実行されるため、図１８に示すように、プロセッサコアＡで実行中のスレッドＬ１がリソースＡのセマフォを取得してリソースＡを操作している際に、スレッドＬ１の優先度がリソースＡのシーリング値「高」に変更されているので、優先度が「中」であるスレッドＭ１は、実行されない。そのため、スレッドＬ１が引き続きリソースＢのセマフォを取得することができ、デッドロックは発生しない。これにより、マルチコアプロセッサにより構成されたリアルタイムシステムにおいて、プライオリティ・シーリング方式を排他処理機構に適用すると共に、デッドロックを回避することができる。
【００３６】
ところで、この手法は、プロセッサコアの使用効率の低下を引き起こしてしまうという問題がある。例えば、図１９に示すように、時刻ｔ０まで、スレッドＭ１とスレッドＭ２は、実行可能状態にあるスレッドの優先度のうちの最高優先度「中」を有するため、プロセッサコアＡとプロセッサコアＢにそれぞれ割り当てられて実行される。しかし、時刻ｔ０において、スレッドＨ１が実行可能状態に遷移したため、スレッドＨ１はプロセッサコアＡに割り当てられて実行され、スレッドＭ１とスレッドＭ２は、スレッドＨ１が実行完了の時刻ｔ１まで中断される。すなわち、時刻ｔ０と時刻ｔ１の間、スレッドＭ１が実行されても問題が無いにも関わらず、プロセッサコアＢにはスレッドが割り当てられず、スレッドＭ１は実行待ちする。これでは、プロセッサコアＢの使用効率が低下し、ひいてはシステム全体の効率が低下する。
【００３７】
この問題点を改良するために、共有リソースのセマフォを取得したスレッドが無い（すなわち排他処理中のスレッドが無い）場合には、その時点において実行可能状態にあるすべてのスレッドを対象に、優先度に基づいてスケジューリングを行う一方、排他処理中のスレッドがある場合には、最も優先度の高いスレッドのみを対象にスケジューリングする手法が考えられる。図２０を参照して説明する。
【００３８】
図２０に示すように、まず、プロセッサコアＡで実行中のスレッドＬ１がリソースＡのセマフォを取得して優先度がリソースＡのシーリング値「高」に変更される。スレッドＬ１がリソースＡのセマフォを解放して優先度が元の「低」に戻される時刻ｔ１までは、スレッドＬ１による排他処理期間である。この期間において、スレッドＭ１が時刻ｔ０で実行可能状態に遷移しても、その優先度がスレッドＬ１の優先度「高」より低いので、スレッドＭ１はスケジューリングの対象にならず、実行されない。
【００３９】
一方、時刻ｔ１において、スレッドＬ１がリソースＡのセマフォを解放したため、排他処理中のスレッドが無くなる。従って、優先度が「低」に戻されたスレッドＬ１と、スレッドＭ１は、共にスケジューリングの対象になり、プロセッサコアＡとプロセッサコアＢでそれぞれ実行される。
【００４０】
処理が進み、時刻ｔ２において、スレッドＭ１はリソースＢのセマフォを取得して排他処理期間に入る。この期間において、スレッドＭ１の優先度がリソースＢのシーリング値「高」に変更されているため、優先度が「低」であるスレッドＬ１は中断される。
【００４１】
また、スレッドＭ１がリソースＢのセマフォを解放した時刻ｔ３からは、排他処理中のスレッドが無いため、スレッドＬ１とスレッドＭ１は、プロセッサコアＡとプロセッサコアＢでそれぞれ実行される。
【００４２】
この手法は、空きプロセッサがあるにも関わらず、実行可能状態のスレッドが実行されていない状況が生じうる期間を、排他処理を行うスレッドがある期間に抑えることによって、プロセッサコアの利用効率をある程度向上させることができる。
【００４３】
ところで、図２０から分かるように、期間「ｔ０〜ｔ１」において、スレッドＭ１が実行されてもシステム上では問題が無いにも関わらず、スレッドＭ１は実行されておらず、プロセッサコアＢは動作していない。同様に、期間「ｔ２〜ｔ３」において、スレッドＬ１が実行されてもシステム上では問題が無いにも関わらず、スレッドＬ１は実行されておらず、プロセッサコアＡは動作していない。これでは、プロセッサコアの利用効率を向上させる効果が弱まる。
【００４４】
このように、マルチコアプロセッサに向けのリアルタイムシステムにおいて、デッドロックや優先度逆転などを回避してシステムの安全性を保つために、マルチコアプロセッサの有用性を犠牲にするという問題がある。
【課題を解決するための手段】
【００４５】
本発明の１つの態様は、複数のプロセッサコアと、複数のスレッドにより共有されうる複数のリソースとを備えたリアルタイムシステムにおけるスレッド制御方法である。この方法は、各リソースのシーリング値に基づいたプライオリティ・シーリング方式で、スレッドによるリソース操作時の排他制御を行うと共に、同一のシーリング値を有するリソースが同一のグループになるように上記複数のリソースをグループ分けし、グループ単位のセマフォ方式でスレッドのスケジューリングを行う。
【００４６】
なお、上記態様の方法を装置やシステム、コンピュータに上記方法を実行せしめるプログラムに置き換えて表現したものも、本発明の態様として有効である。
【発明の効果】
【００４７】
本発明にかかる技術によれば、マルチコアプロセッサ向けのリアルタイムシステムにおいて、安全性を確保すると共に、プロセッサコアの使用効率を確実に向上させることができる。
【発明を実施するための最良の形態】
【００４８】
以下、図面を参照して本発明の実施の形態について説明する。なお、以下の説明に用いられる図面に、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、プロセッサ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリに記録された、またはロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。また、分かりやすいように、これらの図面において、本発明の技術を説明するために必要なもののみを示す。
＜第１の実施の形態＞
【００４９】
図１は、本発明の第１の実施の形態にかかるリアルタイムシステム１００を示す。リアルタイムシステム１００は、複数のプロセッサコア（図示の例では２つ：プロセッサコア１２１、プロセッサコア１２２）と、これらのプロセッサコアで実行されるスレッドにより共有可能な複数の共有リソース（図示の例では６つ：リソースＡ〜Ｆ）と、スレッドのスケジューリング、およびスレッドが共有リソースを操作する際の排他制御を担う制御部１３０を備える。制御部１３０、各プロセッサコア、各共有リソースは、バス１１０を介して接続されている。
【００５０】
本実施の形態のリアルタイムシステム１００において、制御部１３０は、排他制御に際して、プライオリティ・シーリング方式を用いる。前述したように、プライオリティ・シーリング方式は、共有リソースのセマフォを取得したスレッドの優先度を該リソースのシーリング値に一時的に変更する手法である。
【００５１】
例として、スレッドは、優先度が「中」であるスレッドＭ１〜スレッドＭ３と、優先度が「低」であるスレッドＬ１〜Ｌ２があり、リソースは、シーリング値が「高」であるリソースＡと、シーリング値が「中」であるリソースＢ、Ｃ、Ｄと、シーリング値が「低」であるリソースＥ、Ｆがある。
【００５２】
制御部１３０は、スレッドのスケジューリングに際して、同一のシーリング値を有するリソースが同一のグループになるように複数の共有リソースをグループ分けして得たグループ単位のセマフォ方式を用いる。本実施の形態において、セマフォ方式としてバイナリ。セマフォを採用するが、カウンティングセマフォ方式を用いてもよい。
【００５３】
図２は、制御部１３０を示す。制御部１３０は、制御実行部１３２と、リソース管理部１４０と、バイナリ・セマフォ管理部１５０を備える。リソース管理部１４０は、シーリング値管理部１４２とリンク１４４を有し、バイナリ・セマフォ管理部１５０は、セマフォ値管理部１５２と待ちスレッド・キュー１５４を有する。
【００５４】
リソース管理部１４０におけるシーリング値管理部１４２は、リソース毎にシーリング値を記憶している。図３に示すように、リソースＡに対して「高」優先度を示す「Ｈ」、リソースＢ〜Ｄに対して「中」優先度を示す「Ｍ」、リソースＥ〜Ｆに対して「低」優先度を示す「Ｌ」が記憶されている。
【００５５】
バイナリ・セマフォ管理部１５０におけるセマフォ値管理部１５２は、リソースＡ〜Ｆをグループ分けして得たグループ毎のバイナリ・セマフォ（以下単にセマフォという）を記憶している。本実施の形態において、リソースＡ〜Ｆは、同じシーリング値を有するリソースが同一のグループになるようにグループ分けされており、グループ毎にセマフォが付与されている。図４に示すように、シーリング値が「Ｈ」であるリソースＡはセマフォ１が付与されたグループに、シーリング値が「Ｍ」であるリソースＢ〜Ｄは、セマフォ２が付与されたグループに、シーリング値が「Ｌ」であるリソースＥ〜Ｆは、セマフォ３が付与されたグループになるように、リソースＡ〜Ｆはグループ分けされている。セマフォ値管理部１５２は、図５に示すように、それぞれのセマフォの値を記憶している。図５の例では、セマフォ１の値は、セマフォ１に対応するグループ内のリソースのいずれも（ここではリソースＡのみ）スレッドに獲得されておらず、獲得可能であることを示す「０」である。セマフォ２の値は、セマフォ２に対応するグループ内のリソース（リソースＢ〜Ｄ）のいずれかがスレッドにより獲得されており、他のスレッドが該グループ内のいずれのリソースも獲得できないことを示す「１」である。また、セマフォ３の値は、セマフォ２に対応するグループ内のリソース（リソースＥ〜Ｆ）のいずれもスレッドにより獲得されておらず、獲得可能であることを示す「０」である。
【００５６】
バイナリ・セマフォ管理部１５０における待ちスレッド・キュー１５４は、待ちスレッドを一時的に登録する。待ちスレッドは、実行可能状態にありながら、プロセッサコアが割り当てられておらず、実行待ちしているスレッドを意味する。本実施の形態のリアルタイムシステム１００において、スレッドの実行待ちは、すべてのプロセッサコアにおいて該スレッド以上の優先度を有するスレッドが動作している場合の通常実行待ちと、該スレッドが獲得しようとするセマフォが他のスレッドにより獲得されている場合の排他待ちがある。排他待ちしている待ちスレッドに対して、待ちスレッド・キュー１５４は、該スレッドが待っているセマフォの情報も登録する。
【００５７】
リソース管理部１４０におけるリンク１４４は、リソースと、セマフォ値管理部１５２に記憶された該リソースのセマフォ値、および待ちスレッド・キュー１５４に登録された、該リソースのセマフォを待っている待ちスレッドとを対応付けるものである。本実施の形態において、セフォマがグループ毎に付与されているので、以下の本実施の形態の説明において、「リソースのセマフォ」と、「リソースが属するグループのセマフォ」とを同じ意味で用いる。
【００５８】
制御実行部１３２は、スケジューリングに際して、グループ単位のセマフォ方式を用いる。具体的には、下記のスケジューリングポリシを用いる。
１．現時点において実行可能状態にあるスレッドを優先度順にプロセッサコアに割り当てる。例えば、実行可能状態にあるスレッドとして、スレッドＨ１、スレッドＭ１、スレッドＬ１がある場合、まず、スレッドＨ１とスレッドＭ２をプロセッサコア１２１とプロセッサコア１２２でそれぞれ実行させ、その後、空いたプロセッサコアでスレッドＬ１を実行させる。
２．同一優先度の場合は先着順とする。
３．優先度の低いスレッドが実行可能状態になっても、該スレッドの優先度以上の優先度を有するスレッドの実行は中断されない。
４．優先度の高いスレッドが実行可能状態になり、空きプロセッサコアが無い場合には、該スレッドより優先度が低い実行中のスレッドのうちの、最も優先度が低いスレッドの実行を中断してスレッドの切替えを行う。
５．リソースの獲得要求を発行したスレッドに対して、該リソースが属するグループのセマフォが獲得可能であることを条件に、該セマフォを取得させる。
６．リソースの解放要求が発行された際に、該リソースのセマフォ待ちをしている排他待ちのスレッドがあるとき、該排他待ちのスレッドをスケジューリングの対象に入れることで起床させる。
【００５９】
図６と図７のフローチャートを参照して、リソースの獲得要求が発行されたときと、リソースの解放要求が発行されたときの制御実行部１３２の動作を具体的に説明する。
【００６０】
図６に示すように、リソースの獲得要求が発行されたとき、制御実行部１３２は、リンク１４４を追ってセマフォ値管理部１５２を参照して、該リソースのセマフォが獲得可能であるかを確認する（Ｓ１００）。該リソースのセマフォ値が獲得可能を示す「０」であれば、制御実行部１３２は、獲得要求を発行したスレッドに当該セマフォを取得させると共に、該セマフォの値を「１」に書き換える（Ｓ１００：Ｙｅｓ、Ｓ１０２）。一方、セマフォが獲得不能を示す「１」であれば、制御実行部１３２は、該スレッドを排他待ちスレッドとして待ちスレッド・キュー１５４に登録する（Ｓ１００：Ｎｏ、Ｓ１１２、Ｓ１１４）。Ｓ１００〜Ｓ１１４までの処理は、バイナリ・セマフォ方式の処理である。
【００６１】
また、ステップＳ１０２においてセマフォを取得したスレッドに対して、制御実行部１３２は、その優先度を当該リソースのシーリング値に変更する（１２０）。この処理は、プライオリティ・シーリング方式の処理である。
【００６２】
リソースの解放要求が発行されたとき、図７に示すように、制御実行部１３２は、まず、該リソースのセマフォを解放する（Ｓ２００）。具体的には、セマフォ値管理部１５２に記憶された該リソースのセマフォを「１」から「０」に書き換える。そして、待ちスレッド・キュー１５４に、該セマフォを待っている排他待ちスレッドの有無を確認する（Ｓ２０２）。該当する排他待ちスレッドがあれば、制御実行部１３２は、このスレッドを起床させると共に、待ちスレッド・キュー１５４から削除する（Ｓ２０２：Ｙｅｓ、Ｓ２１２、Ｓ２１４）。ここまでの処理は、バイナリ・セマフォ方式の処理である。
【００６３】
ステップＳ２０２における確認の結果、該当する排他待ちスレッドが無ければ、制御実行部１３２は、リソースを解放したスレッドの優先度を元の優先度に戻す（Ｓ２０２：Ｎｏ、Ｓ２３０）。また、ステップＳ２０２における確認の結果に応じて該当するスレッドが起床させられた場合（Ｓ２０２：Ｙｅｓ、Ｓ２１２〜Ｓ２１４）、制御実行部１３２は、起床した待ちスレッドの優先度を対応するシーリング値に変更すると共に、リソースを解放したスレッドの優先度を元の優先度に戻す（Ｓ２２０、Ｓ２３０）。Ｓ２２０〜Ｓ２３０の処理は、プライオリティ・シーリング方式の処理である。
【００６４】
従来のリソース毎のバイナリ・セマフォ方式において、優先度逆転が発生する原因は、排他処理を行うスレッドが、該スレッドより優先度の高いスレッドの実行をブロックしてしまうことである。これに対して、プライオリティ・シーリング方式は、リソースのセマフォを取得したスレッドの優先度を一時的にシーリング値に変更することによって、優先度逆転の問題を回避する。
【００６５】
また、リソース毎のバイナリ・セマフォ方式において、デッドロックが発生する原因は、リソースのセマフォを取得した全てのスレッドが、当該リソースのセマフォを所有したまま他のリソースを獲得しうることである。プライオリティ・シーリング方式では、あるリソースのセマフォを取得したスレッドの優先度が、該リソースの優先度より高いシーリング値に変更されるため、２つのスレッドが同時に動作する可能性の無いシングルコアプロセッサにおいて、シーリング値より低い優先度を有する他のスレッドが実行されず、デッドロックも生じない。
【００６６】
しかし、マルチコアプロセッサにおいて、プロセッサコアの使用効率を高めるために複数のスレッドが同時に動作可能にすると、プライオリティ・シーリング方式でも、デッドロックが生じうる。
【００６７】
そこで、上述したように、本実施の形態のリアルタイムシステム１００における制御部１３０は、共有リソースのシーリング値を用いてプライオリティ・シーリング方式で排他制御を行うと共に、シーリング値毎に分けられたグループ単位のセマフォ方式でスケジューリングを行う。したがって、あるリソースを獲得したスレッドが存在するとき、該リソースと同じグループに属するリソースを獲得しようとするスレッドはセマフォ待ちで実行できない。すなわち、同じグループの複数のリソースをそれぞれ取得して別々のプロセッサコアで実行する複数のスレッドが存在するケースがありえない。一方、他のグループのリソースを獲得しようとするスレッドは目的のリソースを取得して別のプロセッサコアで実行可能であり、リソースを獲得しようとしていないスレッドも別のプロセッサコアで実行可能である。さらに、プライオリティ・シーリング方式の規定により、リソースを取得して実行中のスレッドは、該スレッドのそのときの優先度より低いシーリング値のリソースを取得できないので、シーリング値の異なるリソースをそれぞれ獲得して実行している複数のスレッドが存在する場合においても、これらのスレッドが、互いに相手が獲得したリソースを取得し合うことは生じず、デットロックも発生しない。
こうすることにより、デッドロックを回避しつつ、プロセッサコアの有用性の低下を防ぐことができる。
【００６８】
図８に示す動作例を用いてより具体的に説明する。
＜時刻ｔ０＞
プロセッサコア１２１ではスレッドＬ１が動作しており、プロセッサコア１２２では動作するスレッドが無い。
【００６９】
＜時刻ｔ１＞
スレッドＬ１は、リソースＡのセマフォ（セマフォ１）の獲得要求を発行する。
制御実行部１３２は、リソース管理部１４０におけるリンク１４４を追って、バイナリ・セマフォ管理部１５０のセマフォ値管理部１５２に記憶されたセマフォ１の値を確認する。セマフォ１の値が他のスレッドに所有されていないことを示す「０」であるため、制御実行部１３２は、スレッドＬ１にセマフォ１を取得させると共に、シーリング値管理部１４２を参照して、スレッドＬ１の優先度をリソースＡのシーリング値「高」に変更する。これに伴って、セマフォ値管理部１５２は、セマフォ１の値を「１」に変更する。
【００７０】
＜時刻ｔ２＞
スレッドＭ１は実行可能状態に遷移する。
制御実行部１３２は、プロセッサの割付状態を確認する。プロセッサコア１２２が空いているので、制御実行部１３２は、スレッドＭ１をプロセッサコア１２２に割り付け、実行させる。すなわち、優先度が「Ｈ」になったスレッドＬ１がプロセッサコア１２１での実行中にもスレッドＭ１がプロセッサコア１２２で実行でき、プロセッサコアの使用効率を高めることができる。
【００７１】
＜時刻ｔ３＞
スレットＭ１はリソースＡのセマフォ（セマフォ１）の獲得要求を発行する。
制御実行部１３２は、リソース管理部１４０におけるリンク１４４を追い、バイナリ・セマフォ管理部１５０のセマフォ値管理部１５２に記憶されたセマフォ１の値を確認する。このとき、セマフォ１がスレッドＬ１に所有されており、その値が「１」であるため、制御実行部１３２は、スレッドＭ１を待ちスレッド・キュー１５４に登録し、その状態を排他待ち状態にする。
【００７２】
＜時刻ｔ４＞
スレッドＬ１はセマフォ１を解放する。これにより、セマフォ値管理部１５２は、セマフォ１の値を「０」に変更する。
制御実行部１３２は、スレッドＬ１の優先度を元の「低」に戻すと共に、リンク１４４を追い、待ちスレッド・キュー１５４を確認する。このとき、待ちスレッド・キュー１５４にスレッドＭ１が登録されているので、制御実行部１３２は、スレッドＭ１を起床させると共に、待ちスレッド・キュー１５４からスレッドＭ１を削除する。また、制御実行部１３２は、セマフォ１をスレッドＭ１に取得させ、スレッドＭ１の優先度をリソースＡのシーリング値「高」に変更する。このときも、優先度が「低」に戻されたスレッドＬ１は、プロセッサコア１２１で実行を続ける。
【００７３】
＜時刻ｔ５＞
スレッドＬ１はリソースＢのセマフォ（セマフォ２）の獲得要求を発行する。
制御実行部１３２は、リンク１４４を追い、セマフォ値管理部１５２に記憶されたセマフォ２の値を確認する。セマフォ２の値が「０」であるため、制御実行部１３２は、セマフォ２をスレッドＬ１に取得させ、スレッドＬ１の優先度をリソースＢのシーリング値「中」に変更する。これにより、セマフォ値管理部１５２は、セマフォ２の値を「１」に変更する。
【００７４】
すなわち、リソースＡが属するグループのセマフォ（セマフォ１）がスレッドＬ１により獲得されているにもかかわらず、リソースＢが属するグループのセマフォ（セマフォ２）が他のスレッドにより獲得されていなければ、リソースＢのセマフォの獲得が可能になっている。
【００７５】
また、このとき、スレッドＬ１がリソースＢのセマフォ（セマフォ２）を所有したままリソースＡのセマフォ（セマフォ１）を再度要求した場合には、セマフォ１がスレッドＭ１により所有されているため、スレッドＬ１は排他待ちする。一方、スレッドＢは、優先度がＨに変更されており、シーリング値がＭ以下のリソースを獲得する可能性が無いため、スレッドＢからセマフォ２を要求することは無い。そのため、デットロックも生じる可能性が無い。
【００７６】
＜時刻ｔ６＞
スレッドＭ１がリソースＡのセマフォを解放する。
制御実行部１３２は、スレッドＭ１の優先度を元の「中」に戻すと共に、リンク１４４を追い、待ちスレッド・キュー１５４を確認する。このとき、リソースＡの排他待ちスレッドが無いので、制御実行部１３２は、セマフォ値管理部１５２におけるセマフォ１の値を「０」に変更する。
【００７７】
＜時刻ｔ７＞
スレッドＬ１がリソースＢのセマフォを解放する。
制御実行部１３２は、スレッドＬ１の優先度を元の「低」に戻すと共に、リンク１４４を追い、待ちスレッド・キュー１５４を確認する。このとき、リソースＢの排他待ちスレッドが無いので、制御実行部１３２は、セマフォ値管理部１５２におけるセマフォ２の値を「０」に変更する。
【００７８】
その後、スレッドＬ１とスレッドＭ１は、それぞれプロセッサコア１２１とプロセッサコア１２２で実行され続ける。
【００７９】
このように、本実施の形態のリアルタイムシステム１００によれば、優先度逆転やデッドロックなどの問題を回避し安全なシステムを実現すると共に、マルチコアプロセッサの有用性をより生かすことができる。
＜第２の実施の形態＞
【００８０】
本発明の第２の実施の形態も、マルチコアプロセッサにより構成されたリアルタイムシステムである。このリアルタイムシステムと第１の実施の形態のリアルタイムシステム１００とは、共有リソースをグループ分けする際の手法が異なる点以外に、他の構成が同様である。ここで、第２の実施の形態における共有リソースのグループ分けについてのみ説明する。
【００８１】
リアルタイムシステム１００において、同一のシーリング値を有するリソースが同一のグループになるように複数の共有リソースをグループ分けする。こうすることによって、リソースの排他対象は、該リソースと同じシーリング値を有するリソースに限定される。しかし、本発明によるスレッド制御手法によれば、１つのグループ内に、同様のスレッドより獲得される可能性の無いリソースと、他のリソースとの間で排他する必要が無いため、このようなリソースを別グループに分離し、別のセマフォを付与することができる。
【００８２】
したがって、本発明の第２の実施の形態において、第１の実施の形態のリアルタイムシステム１００におけるグループ分けの手法により得られた同一のグループ内のリソースのうちの、同様の１つ以上のスレッドにより操作される可能性のあるリソースから構成されたセットであって、かつ、該セットに対応する上記１つ以上のスレッドが該グループ内の該セット以外のいずれのリソースも操作する可能性が無いセットに含まれるリソースを、別グループにさらに分けている。
【００８３】
図９に示す例を用いて説明する。この例では、共有リソースを操作しうるスレッドは、スレッドＭ１〜Ｍ２、スレッドＬ１〜Ｌ４の６つがある。それぞれのスレッドが獲得する可能性のあるリソースは、スレッドＭ１、スレッドＭ２、スレッドＬ１、スレッドＬ２、スレッドＬ３、スレッドＬ４の順で、「リソースＡ、リソースＢ、リソースＣ」、「リソースＡ、リソースＤ」、「リソースＢ、リソースＥ」、「リソースＡ、リソースＥ」、「リソースＣ、リソースＥ」、「リソースＤ、リソースＦ」である。
【００８４】
また、リソースＡのシーリング値は「高」であり、リソースＢ〜Ｄのシーリング値は「中」であり、リソースＥ〜Ｆのシーリング値は「低」であるとする。
【００８５】
リアルタイムシステム１００において、このような複数のリソースに対して、図４に示すグループ分けがなされ、それぞれのグループにセマフォが付与される。
【００８６】
しかし、図９に示すように、シーリング値が「中」であるリソースＤを獲得する可能性のあるスレッドは、スレッドＬ４とスレッドＭ２である。これらのいずれのスレッドも、シーリング値が「中」である他のリソース（リソースＢとリソースＣ）を獲得対象としない。そのため、本実施の形態において、リソースＤを別グループに分離し、別のセマフォを付与する。
同様に、リソースＥとリソースＦもそれぞれ１つの独立したグループに分けられる。
【００８７】
その結果、図１０に示すように、リソースＡはシーリング値が「高」であるグループに分けられ、セマフォ１が付与される。リソースＢ〜Ｃはシーリング値が「中」であるグループに分けられ、セマフォ３が付与される。リソースＤはシーリング値が「中」である別のグループに分けられ、セマフォ２が付与される。リソースＥは、シーリング値が「低」である１つのグループに分けられ、セマフォ４が付与される。リソースＦは、シーリング値が「低」である別のグループに分けられ、セマフォ５が付与される。
【００８８】
こうすることにより、リソースＤの操作時に、同じシーリング値を有するリソースＢとリソースＣが排他対象にならず、リソースＤの操作時にリソースＢとＣが排他対象にならない。同様に、リソースＥとリソースＦも互いに排他対象にならない。これにより、排他待ちの発生率を抑制することができ、プロセッサコアをより効率良く利用できる。
【００８９】
なお、１つのグループからさらに別グループを分ける際に、別グループの数は１つに限らず、別グループに含まれるリソースの数も１つに限られない。
例えば、シーリング値が「中」であるリソースは、リソースＢ〜Ｅの４つがある。リソースＢを操作する可能性のあるスレッドはスレッドＭ１とスレッドＬ１であり、リソースＣを操作する可能性のあるスレッドも同様である。そこで、スレッドＭ１とスレッドＬ１がリソースＤとリソースＥのいずれも操作対象としない場合には、リソースＢとリソースＣは、同一の別グループに分けられる。これは、一つの別グループに複数のリソースが含まれる例である。
【００９０】
また、たとえば、シーリング値が「中」であるリソースは、リソースＢ〜Ｅの４つがある。リソースＢを操作する可能性のあるスレッドは、スレッドＭ１とスレッドＬ１であり、リソースＣを操作する可能性のあるスレッドは、スレッドＭ１、スレッドＭ２及びスレッドＬ２である。また、リソースＤを操作する可能性のあるスレッドは、スレッドＭ３とスレッドＬ３であり、リソースＥを操作する可能性のあるスレッドは、スレッドＭ４とＬ４である。この場合、リソースＢとリソースＣが同じグループになり、リソースＤとリソースＥは、それぞれ１つの別のグループになる。
【００９１】
以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述した各実施の形態に対して、さまざまな変更、増減、組合せを行ってもよい。これらの変更、増減、組合せが行われた変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００９２】
【図１】本発明の第１の実施の形態にかかるリアルタイムシステムを示す図である。
【図２】図１に示すリアルタイムシステムにおける制御部を示す図である。
【図３】図１に示すリアルタイムシステムにおける各共有リソースに対して設定されたシーリング値の例を示す図である。
【図４】図１に示すリアルタイムシステムにおける共有リソースのグループ分けを示す図である。
【図５】図２に示す制御部におけるバイナリ・セマフォ管理部によるグループ毎のセマフォの管理態様を説明するための図である。
【図６】リソースの獲得要求が発行されたときの、図２に示す制御部における制御実行部の動作を示すフローチャートである。
【図７】リソースの解放要求が発行されたときの、図２に示す制御部における制御実行部の動作を示すフローチャートである。
【図８】図１に示すリアルタイムシステムにおけるスレッドの動作例を示す図である。
【図９】本発明の第２の実施の形態のリアルタイムシステムにおける共有リソースのグループ分けを説明するための図である（その１）。
【図１０】本発明の第２の実施の形態のリアルタイムシステムにおける共有リソースのグループ分けを説明するための図である（その２）。
【図１１】優先度ベースのスケジューリングポリシを説明するための図である。
【図１２】スレッドによる共有リソースの操作時に行う排他処理を説明するための図である。
【図１３】バイナリ・セマフォ方式を説明するための図である。
【図１４】バイナリ・セマフォ方式で生じる優先度逆転問題を説明するための図である。
【図１５】バイナリ・セマフォ方式で生じるデッドロック問題を説明するための図である。
【図１６】プライオリティ・シーリング方式を説明するための図である。
【図１７】マルチコアプロセッサ向けのリアルタイムシステムの排他処理機構にプライオリティ・シーリング方式を適用した際に生じるデッドロックを説明するための図である。
【図１８】マルチコアプロセッサ向けのリアルタイムシステムの排他処理機構にプライオリティ・シーリング方式を適用すると共に、デッドロックの発生を回避可能な手法を説明するための図である。
【図１９】図１９に示す手法の問題点を説明するための図である。
【図２０】マルチコアプロセッサ向けのリアルタイムシステムの排他処理機構にプライオリティ・シーリング方式を適用すると共に、デッドロックの発生を回避可能な他の手法および該手法の問題点を説明するための図である。
【符号の説明】
【００９３】
１００  リアルタイムシステム
１１０  バス
１２１  プロセッサコア
１２２  プロセッサコア
１３０  制御部
１３２  制御実行部
１４０  リソース管理部
１４２  シーリング値管理部
１４４  リンク
１５０  バイナリ・セマフォ管理部
１５２  セマフォ値管理部
１５４  待ちスレッド・キュー
【図１】
2010020683.tif 000003
【図２】
2010020683.tif 000004
【図３】
2010020683.tif 000005
【図４】
2010020683.tif 000006
【図５】
2010020683.tif 000007
【図６】
2010020683.tif 000008
【図７】
2010020683.tif 000009
【図８】
2010020683.tif 000010
【図９】
2010020683.tif 000011
【図１０】
2010020683.tif 000012
【図１１】
2010020683.tif 000013
【図１２】
2010020683.tif 000014
【図１３】
2010020683.tif 000015
【図１４】
2010020683.tif 000016
【図１５】
2010020683.tif 000017
【図１６】
2010020683.tif 000018
【図１７】
2010020683.tif 000019
【図１８】
2010020683.tif 000020
【図１９】
2010020683.tif 000021
【図２０】
2010020683.tif 000022