JP4006428B2 - 計算機システム - Google Patents

Description

本発明は、仮想計算機マネージャによって構築される仮想計算機環境で、複数の仮想プロセッサが動作するマルチプロセッサ環境を前提としてゲストＯＳが動作する計算機システムに係り、特に、複数の仮想プロセッサの中から処理を実行させる仮想プロセッサを選択して、その選択された仮想プロセッサに実プロセッサを割り当てるのに好適な計算機システムに関する。

近年、パーソナルコンピュータ等の計算機システムにおいて、仮想計算機（Virtual Machine）システム（以下、ＶＭシステムと称する）を実現するためのアプリケーション（アプリケーションプログラム）が利用されるようになってきている。このようなアプリケーションは、ＶＭ（Virtual Machine）アプリケーションと呼ばれる。

さて、計算機システム（実計算機システム）は、一般に、実プロセッサ、各種Ｉ／Ｏ（入出力）装置及びメモリ（図示せず）等のハードウェア（ＨＷ）で構成されている。この計算機システムのハードウェア構成上では、ホストＯＳと呼ばれるＯＳが動作する。ホストＯＳ上では各種アプリケーションが実行される。このアプリケーションの１つが上記ＶＭアプリケーションである。このＶＭアプリケーションの実行により、ＶＭシステムを管理する仮想計算機マネージャ（Virtual Machine Manager、以下、ＶＭＭと称する）が実現される。ＶＭＭは、仮想プロセッサ、仮想Ｉ／Ｏ（入出力）装置及び仮想メモリ装置を含む仮想ＨＷを実現する。ＶＭＭは、これらの仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想
メモリ装置をエミュレートして、仮想計算機実行環境を構築（提供）する。ＶＭＭは、この仮想計算機実行環境にゲストＯＳと呼ばれる適切なＯＳをロードし、実行する。具体的には、ＶＭＭは、仮想ＨＷとしての仮想メモリ装置にゲストＯＳのコードを展開し、その実行コードを仮想プロセッサのエミュレートという形で実行することで、ゲストＯＳの処理を進める。ゲストＯＳからのＩ／Ｏ要求は、ＶＭＭが仮想Ｉ／Ｏ装置のエミュレートを行うことにより処理される。

さて、ゲストＯＳがマルチプロセッサ環境を要求しているときには、仮想プロセッサを複数用意することで対応できる。計算機システム（ホストシステム）がマルチプロセッサシステムである場合には、それら複数の仮想プロセッサを、ある程度同時に並列に処理することが可能である。しかし一般的には、全ての仮想プロセッサに対して実プロセッサが同時に割り当てられる保証はない。このような事態は、例えば、実プロセッサの数が仮想プロセッサより少ない場合に起きる。また、計算機システム内の他の処理（アプリケーションやＯＳ本体の処理）を、実プロセッサが実行しなければならない場合にも、このような事態は起きる。つまり計算機システム内では、一部の実プロセッサしかＶＭＭアプリケーションに割り当てられないタイミングがある。このため、仮想プロセッサが複数存在する場合、時間を決めて、一部の仮想プロセッサを選択して実プロセッサを割り当てるのが一般的である。この場合、選択された仮想プロセッサで処理が実行されることにより、システム全体の処理が進められる。

このように、ＶＭＭは一般的な計算機システム（以下、第１の計算機システムと称する）内で、仮想的な計算機実行環境（仮想計算機実行環境）を構築して、その中でゲストＯＳを実行することができる。ここでは、ＶＭＭは、ＯＳ上で動作する１つのアプリケーション（ＶＭアプリケーション）として実装される。

この他に、ＶＭＭが、計算機システムの実ＨＷ上にＶＭ機構（ＨＷとしての仮想計算機支援機構）として実装される構成も知られている。この計算機システム（以下、第２の計算機システムと称する）において、ＶＭ機構は、上記第１の計算機システム内のＶＭアプリケーションと同様に、実プロセッサ、実Ｉ／Ｏ装置及び実メモリ装置を仮想化して各ゲストＯＳに機能として提供する。つまりＶＭ機構は、仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置をエミュレートする。またＶＭ機構は、実プロセッサ、実Ｉ／Ｏ装置及び実メモリ装置等のＨＷリソースを、時間的、領域的（空間的）に仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置に割り当てる。このようにしてＶＭ機構の上には、仮想計算機実行環境が当該ＶＭ機構により構築される。ゲストＯＳは、この仮想計算機実行環境にロードされて、仮想プロセッサにより実行される。ここで、ゲストＯＳがマルチプロセッサ構成を要求している場合、仮想プロセッサは複数用意される。この場合も、全ての仮想プロセッサに対して、実プロセッサを同時に割り当てることは必ずしもできない。その理由としては、例えば実プロセッサ数が元々足りない場合がある。また、他のゲストＯＳの実行のために、一部の実プロセッサが使用されている場合もある。

上記第１または第２の計算機システムでは、ＶＭアプリケーションまたはＶＭ機構により、複数の仮想プロセッサの中から、細かい時間毎にいずれかの仮想プロセッサが選択される。そして、選択された仮想プロセッサの処理が、決められた時間、あるいはある事象が発生するまで、実プロセッサによりエミュレートされることで進められる（時分割処理）。このような処理が、全ての仮想プロセッサに対して、例えば順番に行われることにより、ゲストＯＳ全体としての処理が進行する。

上記第１または第２の計算機システムにおいて、ゲストＯＳがマルチプロセッサをサポートするＯＳで、かつＶＭＭがマルチプロセッサ構成の仮想ＨＷをエミュレートするものとする。このようなゲストＯＳでは、カーネル内部でスピンロックによる排他制御が行われることが多い。スピンロックは、変数（スピンロック変数）をフラグのように使い、それをＴＡＳ（Test And Set）命令などで排他的に変更することにより、排他制御区間に入れる排他制御対象を高々１つに限定する手法であり、一般的なマルチプロセッサシステムのＯＳで広く使われているものである。ゲストＯＳでの排他制御対象は仮想プロセッサである。また、スピンロック変数は、排他制御が必要となるデータ（キュー、リスト等のデータ）、あるいは処理（処理コード）毎、即ち実行対象毎に用意される。

ここで、ＶＭＭが動作させるゲストＯＳがマルチプロセッサＯＳで、かつ複数のプロセッサ、例えば４つのプロセッサの存在を前提としているものとする。この場合、ＶＭＭはゲストＯＳ実行時に４つの仮想プロセッサに対してゲストＯＳのコードを実行させる必要がある。計算機システムが潤沢に実プロセッサを備えており、これら仮想プロセッサの全てに同時に実プロセッサを割り当てることができることが理想である。しかし、ゲストＯＳが使う仮想プロセッサの数が実プロセッサ以下という条件は常には望むことはできない。そのため、一般的には、ＶＭＭがゲストＯＳの仮想プロセッサを選択して、限られた実プロセッサを割り当てることになる。そしてＶＭＭは、一定時間、その仮想プロセッサの処理を進めた後、他の仮想プロセッサを選択して処理を進める手順、即ちスケジューリングを繰り返す。勿論、使える実プロセッサ数が複数なら、複数の仮想プロセッサを選ぶことも可能である。

前述した計算機システム（第１または第２の計算機システム）において、ゲストＯＳ内の各仮想プロセッサは、必要に応じてスピンロックを確保して排他制御区間内で処理を実行する。この計算機システムには、ロックが解除されるまでスピンロック変数を繰り返しテストする状態、つまりスピンロックをビジーウェイト（スピンループ）している状態の仮想プロセッサも存在し得る。もし、実プロセッサ数が仮想プロセッサ数より少ない場合には、ＶＭＭは同時実行できる仮想プロセッサを選択しなければならない。そこで従来の計算機システムのスケジューリングでは、各仮想プロセッサの状態に無関係に、例えばラウンドロビン法により一定の順番で仮想プロセッサが選択される。このため、スピンロックの解放を待ってビジーウェイトしている状態の仮想プロセッサが選択される可能性がある。この場合、次の仮想プロセッサの選択のタイミングまで、ビジーウェイトの処理のみが行われてしまい、有益な処理が何も行われないことになる。特に、仮想プロセッサ同士での取り合いが頻繁に行われるスピンロック変数が存在する場合には、そのような状況が頻発し、結果的に処理速度の低下を招く。

以上は、スピンロックによる排他制御が仮想プロセッサに適用された例である。この他に、スピンロックによる排他制御を、アプリケーションとしてのプロセス内のスレッド（ＯＳ上で動作するマルチスレッドプログラム）に適用した技術（以下、先行技術と称する）も知られている（例えば、特許文献１参照）。この先行技術の特徴は、スレッド間でスピンロックを用いた排他制御を行っている場合に、ＯＳのスケジューラがスピンロック待ち状態のスレッド以外を選択して効率よくプロセッサを使用する点にある。特許文献１には、アプリケーションのスレッドが「スピンロック待ち状態」になった場合に、スピンロックに使うスピンロック変数（共有変数）のアドレスをＯＳのスケジューラが知ることができる仕組みが記載されている。この仕組みにより、ＯＳのスケジューラは、スレッドをディスパッチ候補として選択したときに、そのスレッドがスピンロック待ち状態か否かの判断をすることができる。そして上記特許文献１では、一定の順番でスレッドを選択する選択手法ではなくて、スピンロック待ちではないスレッドを優先的に選択する選択手法を適用することにより、無駄なスピンループを避けるようにしている。なお、スレッドも仮想プロセッサも、一種のプログラム実行単位である点では共通する。
特開平５−２０４６７５（段落０００７乃至００１１、段落００５４）

上述のように、上記先行技術では、スピンロック待ちではないスレッドを優先的に選択する選択手法（以下、選択手法１と称する）により、無駄なスピンループを避けるようにしている。そこで、この選択手法１を、ゲストＯＳにおける仮想プロセッサの選択に適用することが考えられる。しかし、上記先行技術においては、ディスパッチ時にスピンロック待ち状態でないスレッドを選択しても、その後、この選択されたスレッドが、他のスレッドの確保した（そして現在当該他のスレッドに実プロセッサが割り当てられていない状態における）スピンロックの待ち状態になった場合には、やはり無駄にスピンループしてしまう事態が発生し得る。この点において、上記先行技術は、スケジューラが新たなスレッドを選択する際に限って効果がある技術であるといえる。つまり、上記先行技術は、スレッドの実行効率を確かに改善することができるものの、アプリケーションレベルでのみ効果がある技術であるといえる。

したがって、上記選択手法１をゲストＯＳにおける仮想プロセッサの選択に適用して、ＶＭＭがスピンロック待ちではない仮想プロセッサを優先的に選択し、その選択された仮想プロセッサに実プロセッサを割り当てるだけでは、選択された仮想プロセッサは、その後、実プロセッサが割り当てられていない、つまり非実行中の状態にある仮想プロセッサが確保しているスピンロックの待ち状態になってスピンループを発生する虞がある。この場合、ゲストＯＳの性能低下（処理速度の低下）を招く。

アプリケーションレベルの排他制御の影響は、そのアプリケーションの効率だけに止まり、他のアプリケーションに影響を与えるものではない。なぜなら、ＯＳが各アプリケーション毎に平等にプロセッサを割り当てようとするからである。ところが、上記選択手法１をゲストＯＳにおける仮想プロセッサの選択に適用することで、非実行中の状態にある仮想プロセッサが確保しているスピンロックの待ち状態になってスピンループを発生すると、アプリケーションのスレッドのスピンループとは異なり、（ＯＳ上のアプリケーションを含めて）ＯＳ全体の処理が止まってしまう可能性がある。

これらの理由から、ＶＭＭによりマルチプロセッサ環境を前提としたゲストＯＳを実行する際には、スピンロック変数を利用したスピンロックの処理に関して注意が必要であり、上記先行技術とは違った、より効率の良いスピンロックの扱いが要求される。

本発明は上記事情を考慮してなされたものでその目的は、選択された仮想プロセッサが不要にスピンループして処理効率が悪くなるという問題を解決して、システム全体の効率を良くすることができる計算機システムを提供することにある。

本発明の１つの観点によれば、仮想計算機マネージャによって構築される仮想計算機環境で、複数の仮想プロセッサが動作するマルチプロセッサ環境を前提としてゲストＯＳが動作し、上記複数の仮想プロセッサ間の排他制御に、予め定められた処理毎に用意されるスピンロック変数が用いられる計算機システムが提供される。この計算機システムは、選択手段及びプロセッサ割り当て手段を備えている。選択手段及びプロセッサ割り当て手段は、それぞれ上記仮想計算機マネージャに設けられている。選択手段は、上記複数の仮想プロセッサの中から、目的の実行対象に関するスピンロックを取得していて、かつ実プロセッサが割り当てられていない非実行中の状態にある仮想プロセッサを優先的に選択する。プロセッサ割り当て手段は、選択手段によって選択された仮想プロセッサに実プロセッサを割り当てる。

このように、上記構成の計算機システムにおいては、上記先行技術における「スピンロック待ちではないスレッド」に相当する、「スピンロック待ちでない仮想プロセッサ」ではなくて、「スピンロックを取得していて、かつ非実行中の状態にある仮想プロセッサ」、つまり「スピンロックを取得しているが、実プロセッサが割り当てられていないために処理が中断された状態にある仮想プロセッサ」が優先的に選択されて、その選択された仮想プロセッサに実プロセッサが割り当てられる。これにより、選択された仮想プロセッサは、既にスピンロックを取得している状態にあることから、スピンループして待ちの状態になることはなく、直ちに処理を実行して早期にスピンロックを解放できる。これにより、他の仮想プロセッサのスピンロック待ちの状態を速やかに解消して、結果としてシステム全体の効率を良くすることができる
ここで、上記複数の仮想プロセッサのうちのいずれかの仮想プロセッサがスピンロックの取得に失敗したことを検出する検出手段と、スピンロックの取得に失敗したことが当該検出手段によって検出された場合に、上記選択手段を呼び出す手段とを追加して、スピンロックの取得に失敗したことが検出された場合に、当該取得に失敗したスピンロックを取得していて、かつ非実行中の状態にある仮想プロセッサが上記選択手段により優先的に選択される構成とすると良い。

このような構成においては、仮想プロセッサがスピンロックの取得に失敗し、そのことが検出手段によって検出された場合には、その時点で選択手段が呼び出され、仮想プロセッサ選択のやり直しの機会が作られる。つまり、再スケジューリングが行われる。これにより、例えば、一旦選択された仮想プロセッサが、他の仮想プロセッサの取得しているスピンロックをとろうとして失敗しても、無駄なスピンループが発生しかけた時点で、そのスピンロックを取得していて、かつ非実行中の状態にある仮想プロセッサを優先的に選択することが可能となり、無駄なスピンループを防止して、より効率よくプロセッサを利用することができる。

上述の再スケジューリングを、仮想プロセッサがスピンロックの取得に失敗した場合だけでなく、例えばスピンロックの解放時にも実行するようにすると良い。但し、スピンロックの解放時の再スケジューリングでは、任意のスピンロックを取得しており、スピンロック待ちでなく、かつ非実行中の状態にある仮想プロセッサが優先的に選択される。ここで、選択すべき仮想プロセッサの候補が複数存在する場合、その時点において最も多くのスピンロックを取得している仮想プロセッサを選択すると良い。

ゲストＯＳ内の仮想プロセッサ間の排他制御では、複数のスピンロックをネストして（入れ子の状態で）取得して、排他的な処理を行うことが多い。そのような場合に、更に他の仮想プロセッサを待たせる可能性が高くなる。そこで、上述のように、最も多くのスピンロックを取得している仮想プロセッサを選択するならば、他の仮想プロセッサを待たせる可能性を効果的に低減できる。

本発明によれば、仮想計算機マネージャによって構築される仮想計算機環境上でマルチプロセッサ環境を前提としたゲストＯＳが動作する計算機システム（仮想計算機システム）において、スピンロックを取得していて、かつ実プロセッサが割り当てられていない非実行中の状態にある仮想プロセッサを優先的に選択して、その選択された仮想プロセッサに実プロセッサを割り当てることにより、選択された仮想プロセッサによりビジーウェイトの処理のみが行われて、つまり選択された仮想プロセッサが不要にスピンループして、処理効率が悪くなる不具合を防止でき、更に選択された仮想プロセッサが取得しているスピンロックが早期に解放され、他の仮想プロセッサのスピンロック待ちの状態を速やかに解消して、結果としてシステム全体の効率を良くし、処理速度の向上を図ることができる。

以下、本発明の一実施形態につき図面を参照して説明する。

図１は本発明の一実施形態に係る、仮想計算機システムを実現する計算機システム１の構成を示すブロック図である。計算機システム（ホストシステム）１は、実計算機を構成するハードウェア（ＨＷ）１０を備えている。ＨＷ１０は、例えば２つの実プロセッサ１０１-0（Ｐ0），１０１-1（Ｐ1）、各種Ｉ／Ｏ装置１０２及びメモリ（図示せず）を含む。ＨＷ１０上では、ホストＯＳと呼ばれるＯＳ２０が動作する。ＯＳ２０上では仮想計算機アプリケーション（ＶＭアプリケーション）３０を含む各種のアプリケーションが実行される。

ＶＭアプリケーション３０の実行により、仮想計算機マネージャ（Virtual Machine Manager、以下、ＶＭＭと称する）３１が実現される。ＶＭＭ３１は、仮想計算機システム（ＶＭシステム）の環境（仮想計算機実行環境）３２を構築する。仮想計算機実行環境３２は、仮想ＨＷ環境（仮想ＨＷ装置）３３及びゲストＯＳ実行環境３４からなる。仮想ＨＷ環境３３は、複数の仮想プロセッサ、例えば４つの仮想プロセッサ３３１-0（ＶＰ0）〜３３１-3（ＶＰ3）、仮想Ｉ／Ｏ装置３３２及び仮想メモリ装置（図示せず）を含む。ＶＭＭ３１は、論理的に、この仮想ＨＷ環境３３内の仮想プロセッサ３３１-0〜３３１-3、仮想Ｉ／Ｏ装置３３２及び仮想メモリ装置をエミュレートして、仮想計算機実行環境３２を実現する。ＶＭＭ３１は、仮想計算機実行環境３２内のゲストＯＳ実行環境３４に、当該ゲストＯＳ実行環境３４で動作するＯＳをゲストＯＳ３４０としてロードする。ＶＭＭ３１は、仮想ＨＷ環境３４に含まれる仮想メモリ装置にゲストＯＳ３４０のコードを展開し、その実行コードを仮想プロセッサ３３１-i（ｉ＝０，１，２，３）のエミュレートという形で実行する。これによりＶＭＭ３１は、ゲストＯＳ３４０の処理を進める。ゲストＯＳ３４０からのＩ／Ｏ要求は、ＶＭＭ３１が仮想Ｉ／Ｏ装置３３２のエミュレートを行うことにより処理する。

ゲストＯＳ３４０のカーネル内には、仮想プロセッサ３３１-0（ＶＰ0）〜３３１-3（ＶＰ3）の排他制御に用いられる共有変数としてのスピンロック変数が存在する。スピンロック変数は、排他制御を必要とする処理毎に存在する。図１の例では、４つのスピンロック変数＃０，＃１，＃２，＃３が存在する。このスピンロック変数＃０，＃１，＃２，＃３は、ゲストＯＳ３４０からアクセス可能なメモリ上のアドレスaddr0，addr1，addr2，addr3に格納されている。この「スピンロック変数のアドレス」を、「スピンロックのアドレス」または「ロックアドレス」と呼ぶこともある。

ＶＭＭ３１は、４つの仮想プロセッサ３３１-0〜３３１-3のいずれかに、実プロセッサ１０１-0，１０１-1のいずれかを割り当てて、仮想プロセッサの処理のエミュレーションを行う。図１の計算機システム１では、説明の簡略化のために、１つのゲストＯＳ３４０のみが存在する場合を想定している。しかし、一般的には計算機システム１内に複数のゲストＯＳが存在する場合もある。その際には、２つの実プロセッサ１０１-0，１０１-1が、別々のゲストＯＳに割り当てられる状況もある。したがって、特定のゲストＯＳに着目すると、そのゲストＯＳに割り当てられる実プロセッサの数は、一般的には「実プロセッサ数以下」あるいは「高々実プロセッサ数」ということになる。

ＶＭＭ３１は、スピンロック変数アドレステーブル３１１及びVPROC_TBL３１２の２つの管理テーブルを有している。この２つの管理テーブルは、ゲストＯＳ３４０に対応して用意される。したがって、計算機システム１内に複数のゲストＯＳが存在する場合には、その複数のゲストＯＳの各々に対応して、それぞれスピンロック変数アドレステーブル３１１及びVPROC_TBL３１２が用意される。

スピンロック変数アドレステーブル３１１は、ゲストＯＳ３４０から通知があったスピンロック変数＃ｉに関して、そのアドレス（スピンロックのアドレス）addriを保持するのに用いられる。スピンロック変数アドレステーブル３１１に保持されるアドレスは、ゲストＯＳ３４０から値が参照できるアドレスである必要がある。スピンロック変数アドレステーブル３１１のデータ構造例を図２に示す。本実施形態では、図１に示されるように、ゲストＯＳ３４０のカーネル内に４つのスピンロック変数＃０〜＃３が存在する。そこで、図２のスピンロック変数アドレステーブル３１１には、その４つのスピンロック変数＃０〜＃３のアドレスaddr0〜addr3が登録されている状態が示されている。

VPROC_TBL３１２は、管理対象のゲストＯＳ３４０で動作する各仮想プロセッサ（ここでは仮想プロセッサ３３１-0〜３３１-3）の状態を管理するのに用いられる仮想プロセッサ状態テーブルである。VPROC_TBL３１２のデータ構造例を図３に示す。図３から明らかなように、VPROC_TBL３１２は、仮想プロセッサ３３１-1〜３３１-3のＩＤ（例えば仮想プロセッサ番号０〜３）でインデックスされている。つまり、VPROC_TBL３１２のエントリｉには、仮想プロセッサ番号がｉ（ＩＤ＝ｉ）の仮想プロセッサ３３１-iの状態情報が保持される。仮想プロセッサ３３１-iの状態情報は、実行ステータス、ロック取得個数及びロック待ちステータスを含む。

実行ステータスは、管理対象のゲストＯＳ３４０で動作する仮想プロセッサ３３１-iが現在実行中の状態にあるか否かを表す。ここでは、実行ステータスは、仮想プロセッサ３３１-iが、現在ＶＭＭ３１によって実プロセッサ１０１-j（ｊは０または１）を割り当てられている状態（実プロセッサ１０１-jによりエミュレーション中）にある場合に実行中の状態を示す１に、そうでないときには非実行中の状態を示す０にセットされる。
ロック取得個数は、仮想プロセッサ３３１-iが現在取得しているスピンロックの個数を示す。

ロック待ちステータスは、仮想プロセッサ３３１-iが現在ロック待ち状態にあるか否かを示す。ロック待ちステータスは、ロック待ち状態にあれば１に、そうでないならば０にセットされる。実行ステータス、ロック取得個数及びロック待ちステータスの各々は、ＶＭＭ３１によって操作される。

図４は、本実施形態で適用されるスピンロック変数のフォーマットを示す。図４の例では、スピンロック変数は３２ビット（４バイト）で構成されており、OWNER_PROC_ID（ビット３１〜２７の５ビット）と、WAIT_PROC_BIT_MAP（ビット２６〜１１の１６ビット）と、LOCK_BIT（ビット０）とを含む。ここでは、ビット１０〜１の１０ビットは空きビットである。

OWNER_PROC_ID（ロック所有プロセッサＩＤ）は、ロックを確保した仮想プロセッサ３３１-iのＩＤ（仮想プロセッサ番号）を示す。OWNER_PROC_IDは、LOCK_BITがセットされている場合にのみ有効である。
WAIT_PROC_BIT_MAP（ロック待ちプロセッサビットマップ）は、ロックを待っている仮想プロセッサの集合を示すビットマップである。本実施形態では、WAIT_PROC_BIT_MAPは１６ビットであり、仮想プロセッサの数が１６個までのシステムに適用可能である。ここでは、WAIT_PROC_BIT_MAPの各ビット（ビット２６〜１１）は、仮想プロセッサ番号１５〜０の仮想プロセッサに対応する。したがって、OWNER_PROC_IDの最上位ビットは０である。なお、OWNER_PROC_IDをビット３０〜２７の４ビットで構成し、ビット３１を空きビットとしても良い。
LOCK_BIT（ロックビット）は、ロックされているか否かを示す。LOCK_BITは、ロックされているとき１に、そうでないとき０にセットされる。

以上により、上記フォーマットのスピンロック変数のアドレスを保持するスピンロック変数アドレステーブル３１１及び仮想プロセッサ３３１-0〜３３１-3の状態を保持するVPROC_TBL（プロセッサ状況テーブル）３１２は、等価的に、仮想プロセッサ各々のスピンロックの取得状況を保持するスピンロック取得状況保持手段を構成していると見なせる。

本実施形態では、ゲストＯＳ３４０はＶＭＭ３１に対し、以下に列挙されるインターフェイス
１）ゲストＯＳが使うスピンロックのアドレスのＶＭＭへの登録
vmm_register_spinlock_address()
２）ＶＭＭへ登録されたスピンロックの使用開始の宣言
vmm_start_use_spinlock()
３）ゲストＯＳが使うスピンロック確保処理
vmm_acquire_spinlock()
４）ゲストＯＳが使うスピンロック解放処理
vmm_release_spinlock()
５）ＶＭＭへ登録したスピンロックの使用終了（中断）の宣言
vmm_end_use_spinlock()
６）ゲストＯＳが使うスピンロックのアドレスのＶＭＭからの登録解除
vmm_deregister_spinlock_address()
を使って「スピンロックの状況」等を通知する。これらインターフェイスは、ＶＭＭ３１の機能を呼び出すためのシステムコールとしてゲストＯＳ３４０に提供される。ここでは、各インターフェイスは、予めライブラリのような形でゲストＯＳ３４０に呼び出し方法が提供されているものとする。

以下、上記各インターフェイスについて順に説明する。
１）ゲストＯＳが使うスピンロックのアドレスのＶＭＭへの登録
vmm_register_spinlock_address()
引数は「スピンロックのアドレス」である。後述するスピンロックの管理方法でゲストＯＳ３４０がＶＭＭ３１にスピンロックを管理してもらいたいときには、当該ゲストＯＳ３４０は予めこのインターフェイスを呼び出して「スピンロックのアドレス」をＶＭＭ３１に通知する。この結果、「スピンロックのアドレス（スピンロック変数のアドレス、つまりロックアドレス）」はスピンロック変数アドレステーブル３１１に登録され、後述するようにＶＭＭ３１によるロックの管理の対象になる。

２）ＶＭＭへ登録されたスピンロックの使用開始の宣言
vmm_start_use_spinlock()
引数は「スピンロックのアドレス」である。ゲストＯＳ３４０は、上記１）で登録されたスピンロックを実際に使用する前に、このインターフェイスを呼び出して使用開始をＶＭＭ３１に教える。ＶＭＭ３１は、このインターフェイスの呼び出しの後に、スピンロック変数の値を参照して、仮想プロセッサの実行制御に用いる。よって、ゲストＯＳ３４０は、このインターフェイスを呼び出す前に、予めスピンロック変数の値を適切に初期化しておく必要がある。

３）ゲストＯＳが使うスピンロック確保処理
vmm_acquire_spinlock()
引数は「スピンロックのアドレス」である。このインターフェイスは、ゲストＯＳ３４０がロックを確保（取得）する際に次のように使用される、スピンロック取得インターフェイスである。
ＶＭＭ３１は、仮想プロセッサがロックを取得できる（即ちLOCK_BITが０であった）場合、スピンロック変数のOWNER_PROC_IDに当該仮想プロセッサのＩＤ（仮想プロセッサ番号）をセットし、かつLOCK_BITをセットするという処理を「アトミック」に行う（OWNER_PROC_IDとLOCK_BITをまとめてアトミックに更新）。「アトミック」については後述する。
一方、仮想プロセッサがロックを取得できない（既にLOCK_BITが１だった）場合には、ＶＭＭ３１は、スピンロック変数のWAIT_PROC_BIT_MAP中の、当該仮想プロセッサに固有のビットをセットする。そしてＶＭＭ３１は、必要に応じて、他の仮想プロセッサを選択し直す。仮想プロセッサは、他の仮想プロセッサに切り替えられない限り、ロックを取得できるまでスピンループする。
このインターフェイス（ロック取得インターフェイス）の処理の詳細については、後述する。

４）ゲストＯＳが使うスピンロック解放処理
vmm_release_spinlock()
引数は「スピンロックのアドレス」である。このインターフェイスは、ゲストＯＳ３４０がロックを解放する際に使用される、スピンロック解放インターフェイスである。このインターフェイスの処理（スピンロック解放処理）の詳細については、後述する。

５）ＶＭＭへ登録したスピンロックの使用終了（中断）の宣言
vmm_end_use_spinlock()
引数は「スピンロックのアドレス」である。このインターフェイスは、ゲストＯＳ３４０がＶＭＭ３１に対して、対応するスピンロック変数を参照をしないように要求するのに用いられる。

６）ゲストＯＳが使うスピンロックのアドレスのＶＭＭからの登録解除
vmm_deregister_spinlock_address()
引数は「スピンロックのアドレス」である。このインターフェイスは、ゲストＯＳ３４０がＶＭＭ３１に対して、対応するスピンロック変数をスピンロック変数アドレステーブル３１１から削除するように要求するのに用いられる。

次に、本実施形態の動作について、上記３）のロック取得インターフェイスvmm_acquire_spinlock()の処理（スピンロック取得処理）を例に、図５及び図６のフローチャートを参照して説明する。この処理は、ゲストＯＳ３４０がロック取得インターフェイスを呼ぶことにより、ＶＭＭ３１に制御が移って実行される処理である。正確には、ゲストＯＳ３４０上で動作するある仮想プロセッサ＃ｉがロック取得インターフェイスを呼ぶことにより、ＶＭＭ３１に制御が移って実行される処理である。より正確には、仮想プロセッサ＃ｉのエミュレーション処理として、ゲストＯＳ３４０がロック取得インターフェイスの呼び出しをした次の瞬間に、エミュレーションが一時的にストップして、直接ＶＭＭ３１の処理に戻る（ステップＳ１)。つまりロック取得インターフェイスの呼び出し元は、ゲストＯＳ３４０でもあり、仮想プロセッサ＃ｉでもあるといえる。ロック取得インターフェイスの引数にはスピンロックのアドレス（ロックアドレス）Ａが用いられる。つまり、ゲストＯＳ３４０は、ＶＭＭ３１にスピンロックのアドレスＡを通知するスピンロックアドレス通知手段としての機能を有する。

ＶＭＭ３１はまず、ロック変数（スピンロック変数）が取れたときにロック変数にセットすべき値を生成して、変数W_VALUEに設定する（ステップＳ２）。生成されたロック変数の値のOWNER_PROC_IDには、呼び出し元の仮想プロセッサ＃ｉのＩＤ（仮想プロセッサ番号）がセットされている。また、生成されたロック変数の値のWAIT_PROC_BIT_MAPの全ビットには０がセットされ、LOCK_BITには１がセットされている。次にＶＭＭ３１は、ロックアドレスＡをポインタ変数LOCK_VALUEに設定する（ステップＳ３）。

次にＶＭＭ３１は、以下に述べる排他制御処理（ステップＳ４）を実行する。まずＶＭＭ３１は、ポインタ変数LOCK_VALUEで指定されるメモリ上の内容（値）*LOCK_VALUEを、変数TMPとして設定する（ステップＳ４ａ）。ここでは、LOCK_VALUEはロックアドレスＡである。したがって、*LOCK_VALUEはロックアドレスＡで指定されるメモリ上のスピンロック変数であり、LOCK_BITを含む。次にＶＭＭ３１は、TMP（スピンロック変数の現在の値）中のLOCK_BITが０であるか、つまり対応するスピンロックが解放されていて、呼び出し元の仮想プロセッサ＃ｉによって当該ロックを取得できるかを判定する（ステップＳ４ｂ）。このステップＳ４ｂは、呼び出し元の仮想プロセッサ＃ｉが当該ロックの取得に成功するか、あるいは失敗するかを検出することと等価である。

もし、TMP中のLOCK_BITが０であるならば、ＶＭＭ３１は、メモリ上のロックアドレスＡ（で指定される領域）に、W_VALUEの値をライトする（ステップＳ４ｃ）。つまりＶＭＭ３１は、ロックアドレスＡで指定されるメモリ上のスピンロック変数*LOCK_VALUEとして、W_VALUEの値を設定する。このように、TMP（引数であるロックアドレスＡで指定されるスピンロック変数の現在の値）中のLOCK_BITが０である場合、ロックアドレスＡで指定されるスピンロック変数が、OWNER_PROC_ID＝呼び出し元の仮想プロセッサ＃ｉのＩＤ（＝ｉ）、LOCK_BIT＝１のスピンロック変数に更新されて、ステップＳ４は終了する。

ＶＭＭ３１は、ステップＳ４を終了すると、呼び出し元の仮想プロセッサのＩＤ（仮想プロセッサ番号）で指定されるVPROC_TBL３１２内のエントリの「ロック待ちステータス」を、当該仮想プロセッサが現在ロック待ちでないことを示すために０クリアし、かつ「ロック取得個数」を１インクリメントする（ステップＳ５）。これにより、ロック取得処理は終了する（ステップＳ６）。

このように本実施形態においては、ロック取得インターフェイスvmm_acquire_spinlock()の引数でロックアドレスＡが指定され、当該アドレスＡのスピンロック変数のLOCK_BITが０の場合、ＶＭＭ３１による処理がＳ３→Ｓ４（Ｓ４ａ→Ｓ４ｂ→Ｓ４ｃ）→Ｓ５→Ｓ６の手順で実行される。これにより、呼び出し元の仮想プロセッサはロックを取得できる。この場合、図４のフォーマットのスピンロック変数であって、以下の値
OWNER_PROC_ID＝ロック取得インターフェイスを呼び出した仮想プロセッサ＃ｉのＩＤ（仮想プロセッサ番号）
WAIT_PROC_BIT_MAP＝全て０
LOCK_BIT＝１
が設定されたスピンロック変数がロックアドレスＡで指定されるメモリにアトミックに書き込まれ、呼び出し元のゲストＯＳ３４０に制御が戻る。この状態は、呼び出し元の仮想プロセッサ＃ｉがロックを確保した状態である。「メモリにアトミックに書き込む」とは、複数の仮想プロセッサからのロック取得インターフェイスの呼び出しに応じて、それぞれステップＳ４の排他制御処理が計算機システム内で同時に実行されたとしても、この排他制御処理に関しては互いに不可分に参照と修正が行われることを意味する。例えばインテル社のPentium（登録商標）プロセッサを使っている場合には、ロック付きXCHG命令を使うことにより、ここに述べたステップＳ４ｂ，Ｓ４ｃの処理を連続して行うことができる。このことは、図５及び図６のフローチャートで示されるロック取得処理がゲストＯＳ３４０の処理（ステップＳ１２を除く）として実装されている場合にも同様である。なお、このロック取得処理が、本実施形態のようにＶＭＭ３１内の処理として実装されている場合には、排他的に実行される必要があるステップＳ４とステップＳ１０の両排他制御処理自体を、ＶＭＭ３１内に設けた専用のロック変数を用いることで簡単に実現できる。

一方、TMP中のLOCK_BITが１である場合（ステップＳ４ｂ）、つまり対応するロックが呼び出し元以外の仮想プロセッサによって確保されているために、当該ロックを取得できないことが判定（検出）される場合には、ＶＭＭ３１は次の処理を行う。まずＶＭＭ３１は、TMP（スピンロック変数の現在の値）のWAIT_PROC_BIT_MAP上の、呼び出し元仮想プロセッサ＃ｉのＩＤ（＝ｉ）に対応するビットがセットされている（１である）かを判定する（ステップＳ７）。ステップＳ７の判定がＹｅｓの場合、即ち呼び出し元仮想プロセッサ＃ｉがスピンループ中（ロック待ち）の状態にある場合、ＶＭＭ３１はステップＳ３に戻る。これにより、仮想プロセッサ＃ｉがロックを取得できるまで、Ｓ３→Ｓ４ａ→Ｓ４ｂ→Ｓ７の処理が繰り返される。

これに対し、ステップＳ７の判定がＹｅｓの場合、即ち呼び出し元仮想プロセッサ＃ｉがスピンループ中（ロック待ち）の状態にない場合、ＶＭＭ３１は、TMPのWAIT_PROC_BIT_MAP上の、呼び出し元仮想プロセッサ＃ｉのＩＤ（＝ｉ）に対応するビットをセットする（ステップＳ９）。これにより、仮想プロセッサ＃ｉがスピンループ中（ロック待ち）の状態となったことが示される。次にＶＭＭ３１は、ステップＳ４と同様の排他制御処理（ステップＳ１０）を次のように実行する。

まずＶＭＭ３１は、ポインタ変数LOCK_VALUE（ここでばロックアドレスＡ）で指定されるメモリ上の値*LOCK_VALUEを、変数TMP3として設定する（ステップＳ１０ａ）。この時点における*LOCK_VALUEは、例えば先のステップＳ４ａの実行時点における*LOCK_VALUE（＝TMP）と必ずしも同じであると限らない。つまり、ロックアドレスＡで指定されるメモリ上の値*LOCK_VALUE（スピンロック変数）は、ステップＳ４ａの実行直後からステップＳ１０ａの実行時点までの間に変わっている可能性がある。そこでＶＭＭ３１は、上記ステップＳ４ａにおいて、ロックアドレスＡで指定されるメモリ上の値*LOCK_VALUEをTMPとは別のTMP3に保存する。次にＶＭＭ３１は、TPMとTMP3とが一致しているかを判定する（ステップＳ１０ｂ）。もし、TPMとTMP3とが一致している場合、つまりメモリ上のロックアドレスＡ（で指定される領域）の値がステップＳ４ａの実行時点以降に書き換えられていない場合、ＶＭＭ３１はステップＳ１０ｃを実行する。このステップＳ１０ｃにおいて、ＶＭＭ３１は、メモリ上のロックアドレスＡ（で指定される領域）に、その時点におけるTMP2の値をライトする。このTMP2の値は、先のステップＳ８の実行時点のTMPの値が保存されたTMP2のうち、その後のステップＳ９で呼び出し元仮想プロセッサ＃ｉに対応するWAIT_PROC_BIT_MAP上のビットがセットされたTMP2の値である。ステップＳ１０ｃが実行されると、ステップＳ１０の排他制御処理は終了し、ＶＭＭ３１はステップＳ１１に進む。

これに対し、TPMとTMP3とが一致していない場合（ステップＳ１０ｂ）、つまりメモリ上のロックアドレスＡ（で指定される領域）の値がステップＳ４ａの実行時点以降に書き換えられた場合には、ステップＳ１０ｃが実行されることなく、ステップＳ１０の排他制御処理は終了する。つまりＶＭＭ３１は、呼び出し元仮想プロセッサ＃ｉに対応するWAIT_PROC_BIT_MAP上のビットをセットすべきスピンロック変数が書き換えられてしまったため、ステップＳ１０ｃをスキップしてステップＳ１１に進む。

ステップＳ１１において、ＶＭＭ３１は、呼び出し元の仮想プロセッサのＩＤ（仮想プロセッサ番号）で指定されるVPROC_TBL３１２内のエントリの「ロック待ちステータス」に、当該仮想プロセッサが「現在ロック待ち（スピンロックループ中）である」ことを示すために１をセットする（ステップＳ１１）。次にＶＭＭ３１は、他の仮想プロセッサを選択し直す（再スケジューリングの）ための後述するステップＳ１２を実行して、ステップＳ３に戻る。これにより、ステップＳ１０ｃが実行された場合だけでなく、ステップＳ１０ｃがスキップされた場合にも、ステップＳ４の排他制御処理で仮想プロセッサ＃ｉがロックを取得できるまで、ステップＳ３から始まる処理が繰り返される。その結果、ステップＳ１０ｃがスキップされた場合にも、その後当該ステップＳ１０ｃが実行されて、呼び出し元仮想プロセッサ＃ｉに対応するWAIT_PROC_BIT_MAP上のビットが（ステップＳ９で）セットされたスピンロック変数が、ロックアドレスＡにライトされる。

このように本実施形態においては、ロック取得インターフェイスvmm_acquire_spinlock()の引数でロックアドレスＡが指定され、当該アドレスＡのスピンロック変数のLOCK_BITが１の場合、つまり当該スピンロック変数に対応するスピンロックが取得できない場合、
当該スピンロック変数のWAIT_PROC_BIT_MAPのうちの呼び出し元仮想プロセッサ＃ｉに対応するビットがセットされる（ステップＳ９）。また、呼び出し元仮想プロセッサ＃ｉは、他の仮想プロセッサに切り替えられない限り、ロックが取得できるまでスピンループする（Ｓ３→Ｓ４ａ→Ｓ４ｂ→Ｓ７）。更に、必要に応じて、他の仮想プロセッサの選択のための処理（ステップＳ１２）に切り替えられる。

また、ロックアドレスＡで指定されるスピンロック変数のOWNER_PROC_IDには、対応するロックがいずれかの仮想プロセッサに取得（所有）されている場合には、当該仮想プロセッサのＩＤがセットされる。また、スピンループの状態で、このロックの解放を待っている仮想プロセッサの集合は、ロックアドレスＡで指定されるスピンロック変数のWAIT_PROC_BIT_MAPを参照することによって知ることができる。

なお、ＶＭＭ３１をゲストＯＳ３４０から毎回呼び出すのでは、処理が遅くなる可能性がある。そこで、図５及び図６のフローチャートで示されるロック取得処理を、後述するvmm_resched_with_lock_addr()の処理（ステップＳ１２）を除いて、ゲストＯＳ３４０内で行う（ライブラリ等で提供）構成とすることも可能である。

ところで、ロックを所有している仮想プロセッサが非実行中の状態（つまりＶＭＭ３１が実プロセッサを当該仮想プロセッサに割り当てておらず、処理が中断されている状態）の場合に、他の仮想プロセッサが、このロックの解放を待ってスピンループして待ち続けるのは効率が悪い。但し、いずれ時間が来ればＶＭＭ３１が他の仮想プロセッサの実行に切り替えるので、デッドロックになるわけではない。

そこで本実施形態では、ＶＭＭ３１は、呼び出し元の仮想プロセッサ＃ｉがロックアドレスＡのスピンロック変数に対応するスピンロックの解放を待ってスピンループするときには、ステップＳ１１に続くステップＳ１２で、vmm_resched_with_lock_addr()という当該ＶＭＭ３１のための再スケジューリング関数を呼び出す。以下、この再スケジューリング関数の処理（仮想プロセッサ再スケジューリング処理）について、図７のフローチャートを参照して説明する。

まず、再スケジューリング関数vmm_resched_with_lock_addr()の引数にはロックアドレスＡが用いられる。この場合、ＶＭＭ３１は、メモリ上の、ロックアドレスＡで指定されるスピンロック変数（ロックアドレスＡの値）、つまり現在呼び出し元の仮想プロセッサがスピンループ（ビジーウェイト）しているスピンロックの変数の値を、変数LOCK_VALUEに設定する（ステップＳ２１）。

次にＶＭＭ３１は、LOCK_VALUE（スピンロック変数）中のOWNER_PROC_IDを参照して、現在呼び出し元の仮想プロセッサがスピンループしているスピンロックを所有している仮想プロセッサ（つまりロック所有プロセッサ）のＩＤ（仮想プロセッサ番号）を特定し、当該ＩＤをＰＩＤとして設定する（ステップＳ２２）。次にＶＭＭ３１は、VPROC_TBL３１２を参照して、ＰＩＤで指定される仮想プロセッサ（ロック所有プロセッサ）の現在の状態を得る（ステップＳ２３）。ＶＭＭ３１は、ステップＳ２３で得られたロック所有プロセッサの状態から、当該ロック所有プロセッサが実行中あるいはロック待ちの状態にあるかを判定する（ステップＳ２４）。

もし、ロック所有プロセッサが実行中あるいはロック待ちの状態にないならば（ステップＳ２４）、つまり非実行中かつロック待ちでない状態にあるならば、ＶＭＭ３１は後述するステップＳ２５乃至Ｓ２７をスキップしてステップＳ２８に進む。このステップＳ２８において、ＶＭＭ３１はスピンループしている呼び出し元の仮想プロセッサの実行状態を当該ＶＭＭ３１内にセーブし、当該仮想プロセッサを非実行中の状態にする。またＶＭＭ３１は、呼び出し元の仮想プロセッサに固有のVPROC_TBL３１２内の「実行ステータス」を「非実行中」に設定する。

次にＶＭＭ３１は、呼び出し元の仮想プロセッサを非実行中の状態にした代わりに、ＰＩＤで指定される仮想プロセッサ（ここでは、ロック所有プロセッサ）を選択して、当該ＰＩＤで指定される仮想プロセッサを実行中の状態にする（ステップＳ２９）。即ちＶＭＭ３１は、ＰＩＤで指定される仮想プロセッサに実プロセッサを割り当てて、仮想プロセッサ再スケジューリング処理からの復帰時に実行が開始される状態とする。ステップＳ２９において、ＶＭＭ３１は、ＰＩＤで指定される仮想プロセッサに固有のVPROC_TBL３１２内の「実行ステータス」を「実行中」に設定する。ＶＭＭ３１は、ステップＳ２９を実行すると、仮想プロセッサ再スケジューリング処理を終了する。

これに対し、ロック所有プロセッサが実行中あるいはロック待ちの状態にあるならば（ステップＳ２４）、ＶＭＭ３１はVPROC_TBL３１２を参照する（ステップＳ２５）。そしてＶＭＭ３１は、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサが存在するかを調べる（ステップＳ２６）。

もし、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサが存在しないならば（ステップＳ２６）、ＶＭＭ３１は仮想プロセッサ再スケジューリング処理を終了する。一方、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサが存在するならば（ステップＳ２６）、ＶＭＭ３１はステップＳ２７に進む。このステップＳ２７において、ＶＭＭ３１は、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサを１つ例えばランダムに選択し、その選択された仮想プロセッサのＩＤをＰＩＤとして設定する。次にＶＭＭ３１は上記ステップＳ２８に進み、スピンループしている呼び出し元の仮想プロセッサを非実行中の状態にする。そしてＶＭＭ３１は上記ステップＳ２９に進み、ＰＩＤで指定される仮想プロセッサを選択して、当該ＰＩＤで指定される仮想プロセッサに実プロセッサを割り当てて実行中の状態にする。但し、ここで選択される仮想プロセッサは、ロックを所有している仮想プロセッサが上述の「非実行中」の場合と異なって、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサである。この「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサも、実プロセッサが割り当てられたならば速やかに処理を実行することが可能である。

このように本実施形態においては、呼び出し元の仮想プロセッサ＃ｉがスピンロックの取得に失敗して、当該スピンロックの解放を待ってスピンループするときには、当該スピンロックを所有していて、かつ「非実行中かつロック待ちでない」仮想プロセッサが、仮想プロセッサ再スケジューリング処理で優先的に選択されて、「実行中」の状態に設定される。この結果、ロックが取得されており、かつそのロックを所有する仮想プロセッサが非実行中かつロック待ちでない状態にも拘わらずに、ビジーウェイトし続けて実プロセッサを無駄に使い続けることを避けることができる。その代わり、ロックを所有する仮想プロセッサに制御が渡されて、処理が進むようになるので、早期にロックが解放されるようになる。これにより、ロックが解放されるのを待っていた他の仮想プロセッサもそれだけ早くロックを確保できるようになり、結果としてスピンループに費やされる時間を大幅に少なくすることができる。

また本実施形態においては、呼び出し元の仮想プロセッサ＃ｉがスピンロックを取得できずに、当該スピンロックの解放を待ってスピンループするときに、当該スピンロックを所有する仮想プロセッサが「実行中あるいはロック待ち」である場合には、次善の策として、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサが選択されて、「実行中」の状態に設定される。これにより、少なくとも、「ロック待ち」でなく、かつ「非実行中」の仮想プロセッサが選択された時点では、無駄なスピンループを避けることができる。

次に、本実施形態における、上記４）のスピンロック解放インターフェイスvmm_release_spinlock()の処理（スピンロック解放処理）について、図８のフローチャートを参照して説明する。スピンロック取得インターフェイスの引数にはスピンロックのアドレス（ロックアドレス）Ａが用いられる。

ＶＭＭ３１は、ゲストＯＳ３４０上で動作する仮想プロセッサ＃ｉによってスピンロック解放インターフェイスが呼び出されると、メモリ上のロックアドレスＡに０をライトする（ステップＳ３１）。つまりＶＭＭ３１は、ロックアドレスＡで指定されるスピンロック変数を０に設定する。これにより、LOCK_BITが０となってロックが解放されたことになる。次にＶＭＭ３１は、呼び出し元の仮想プロセッサのＩＤで指定されるVPROC_TBL３１２内のエントリ（つまり呼び出し元の仮想プロセッサに固有のVPROC_TBL３１２内のエントリ）の「ロック取得個数」を１デクリメントする（ステップＳ３２）。

［スピンロック解放処理の変形例］
次に、スピンロック解放処理の変形例について、図９のフローチャートを参照して説明する。まずＶＭＭ３１は、上記ステップＳ３１，Ｓ３２と同様の処理を実行する。即ちＶＭＭ３１は、ロックアドレスＡで指定されるスピンロック変数を０に設定して、ロックを解放すると共に、呼び出し元の仮想プロセッサのＩＤで指定されるVPROC_TBL３１２内のエントリの「ロック取得個数」を１デクリメントする（ステップＳ４１，Ｓ４２）。そしてＶＭＭ３１は、再スケジューリング関数vmm_resched()を呼び出す（ステップＳ４３）。この再スケジューリング関数vmm_resched()は、前述したロックを取得できなかった場合にステップＳ１２で呼び出される再スケジューリング関数vmm_resched_with_lock_addr()と異なって、引数を持たない。以下、このvmm_resched()が呼び出されることにより実行される再スケジューリング関数の処理（仮想プロセッサ再スケジューリング処理）について、図１０のフローチャートを参照して説明する。

まずＶＭＭ３１は、VPROC_TBL３１２を参照して、所定の選択条件を満足する仮想プロセッサを探す（ステップＳ５１）。この所定の選択条件を満足する仮想プロセッサとは、１）非実行中であり、２）ロック待ちでなく、かつ３）最もロック取得個数が多い仮想プロセッサである。ただし、３）ではロックを１つも取得していない仮想プロセッサは対象としない。ＶＭＭ３１は、上記選択条件を満足する仮想プロセッサを探すことができた場合、その選択条件を満足する仮想プロセッサを１つ選択して、ＶＰnextとして設定する（ステップＳ５３）。

次にＶＭＭ３１は、呼び出し元の仮想プロセッサの実行状態を当該ＶＭＭ３１内にセーブし、当該仮想プロセッサを非実行中の状態にする（ステップＳ５４）。このステップＳ５４において、ＶＭＭ３１は、呼び出し元の仮想プロセッサに固有のVPROC_TBL３１２内の「実行ステータス」を「非実行中」に設定する。

次にＶＭＭ３１は仮想プロセッサＶＰnextを選択して、当該仮想プロセッサＶＰnextを実行中の状態にする（ステップＳ５５）。即ちＶＭＭ３１は、仮想プロセッサＶＰnextに実プロセッサを割り当てて、仮想プロセッサ再スケジューリング処理からの復帰時に実行が開始される状態とする。ステップＳ５５において、ＶＭＭ３１は、仮想プロセッサＶＰnextに固有のVPROC_TBL３１２内の「実行ステータス」を「実行中」に設定する。ＶＭＭ３１は、ステップＳ５５を実行すると、仮想プロセッサ再スケジューリング処理を終了する。

このように、スピンロック解放処理の変形例では、当該解放処理の最後に仮想プロセッサ再スケジューリング処理が実行される。この再スケジューリング処理では、上記選択条件を満足する仮想プロセッサが存在するならば、その仮想プロセッサが優先的に選択される。ここで、上記選択条件を満足する仮想プロセッサＶＰnextは、多くのロックをネストして（入れ子の状態で）所有しており、したがって他の仮想プロセッサがそのロックの待ち状態になる可能性が高いと考えられる。そこで、このような仮想プロセッサＶＰnextを優先的に処理させることにより、ロックの解放を早め、他のプロセッサも（必要ならそれら解放されたロックを確保して）処理を進められるような状況にすることができ、無駄なスピンループ処理を減らすことができる。なお、上述の再スケジューリング関数vmm_resched()は、ロック解放時だけではなく、ＶＭＭ３１の汎用のスケジューラ（次に実行すべき仮想プロセッサを選択する処理）に使うことができる。

上記実施形態では、ゲストＯＳが１つの場合で、その中の仮想プロセッサに対する実プロセッサ割り当てを中心に述べた。この実施形態で適用された技術は、より一般的な実装例として、複数ゲストＯＳに跨って、それら複数のゲストＯＳ内の仮想プロセッサに対する実プロセッサ割り当ての際に適用することも可能である。例えば、特定のゲストＯＳ内の全てのロック待ちでない仮想プロセッサに実プロセッサが割り当てられた状態を想定する。この状態では、さらに他のゲストＯＳのVPROC_TBL３１２を参照し、上記実施形態と同様に、スピンロックを所有し、かつ非実行中の（つまり排他制御区間の処理を中断している）仮想プロセッサを選択するといったことが実現可能であり、同様の効果を得ることが期待できる。

また、上記実施形態では、図４に示したフォーマットのスピンロック変数、即ち対応するスピンロックを所有（取得）している仮想プロセッサのＩＤ（OWNER_PROC_ID）、及び当該ロックの解放を待っている仮想プロセッサの情報（WAIT_PROC_BIT_MAP）を含むスピンロック変数が適用されている。しかし、これらの情報を必ずしもスピンロック変数に含める必要はなく、スピンロック変数に関連付けられた他のデータ構造として実装することも可能である。

［他の実施形態］
図１に示される上記実施形態の計算機システム１では、ＶＭＭ３１は、ＯＳ２０上で動作する１つのＶＭアプリケーション３０として実装されている。しかし、図１の計算機システム（第１の計算機システム）１に代えて、図１１に示す計算機システム（第２の計算機システム）１００を適用することも可能である。図１１において、図１と等価な部分には同一符号が付されている。

図２に示す計算機システム１００の特徴は、図１中のＶＭＭ３１に相当するＶＭＭ（ＶＭ機構）３１０が、計算機システム１００の実ＨＷ上に実装されている点にある。このＶＭＭ３１０の機能は、ＶＭＭ３１と同様であり、仮想計算機実行環境３２を構築し、当該仮想計算機実行環境３２中のゲストＯＳ実行環境３４にゲストＯＳ３４０をロードする。ＶＭＭ３１０は、ＶＭＭ３１と同様に、ゲストＯＳ３４０に対応して用意されるスピンロック変数アドレステーブル３１１及びVPROC_TBL３１２の２つの管理テーブルを有する。

なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係る、仮想計算機システムを実現する計算機システムの構成を示すブロック図。 図１中のスピンロック変数アドレステーブル３１１のデータ構造例を示す図。 図１中のVPROC_TBL３１２のデータ構造例を示す図。 同実施形態で適用されるスピンロック変数のフォーマットを示す図。 同実施形態におけるスピンロック取得処理の手順を示すフローチャートの一部を示す図。 同実施形態におけるスピンロック取得処理の手順を示すフローチャートの残りを示す図。 同実施形態における仮想プロセッサ再スケジューリング処理の手順を示すフローチャート。 同実施形態におけるスピンロック解放処理の手順を示すフローチャート。 スピンロック解放処理の変形例を示すフローチャート。 図９のスピンロック解放処理での再スケジューリング関数の呼び出しによって実行される仮想プロセッサ再スケジューリング処理の手順を示すフローチャート。 本発明の他の実施形態に係る、仮想計算機システムを実現する計算機システムの構成を示すブロック図。

符号の説明

１，１００…計算機システム、３１，３１０…ＶＭＭ（仮想計算機マネージャ）、３２…仮想計算機実行環境、３３…仮想ＨＷ環境、３４…ゲストＯＳ実行環境、１０１-0，１０１-1…実プロセッサ、３１１…スピンロック変数アドレステーブル、３１２…VPROC_TBL（仮想プロセッサ状態テーブル）、３３１-0〜３３１-3…仮想プロセッサ、３４０…ゲストＯＳ。

Claims (7)

1. 仮想計算機マネージャによって構築される仮想計算機環境で、複数の仮想プロセッサが動作するマルチプロセッサ環境を前提としてゲストＯＳが動作し、前記複数の仮想プロセッサ間の排他制御のため、ゲストＯＳ内に予め定められた実行対象毎に用意されるスピンロック変数が用いられる計算機システムにおいて、
   前記ゲストＯＳは、
   前記スピンロック変数が格納されているメモリ上の前記ゲストＯＳ内のアドレスであるスピンロックアドレスを前記仮想計算機マネージャに通知するためのスピンロックアドレス通知手段を具備し、
   前記仮想計算機マネージャは、
   前記スピンロックアドレス通知手段が前記スピンロックアドレスを前記仮想計算機マネージャに通知するのに用いられるインターフェイスと、
   前記インターフェイスを用いて通知された前記スピンロックアドレスに基づき前記ゲストＯＳ内のスピンロック変数を参照及び書き換えするためのスピンロック変数参照・書き換え手段と、
   前記スピンロック変数参照・書き換え手段により参照及び書き換えされる前記スピンロック変数に基づく排他制御の処理を行う排他制御手段と、
   前記スピンロック変数参照・書き換え手段によるスピンロック変数の参照結果に基づき、前記複数の仮想プロセッサの中から、目的の実行対象に関するスピンロックを取得していて、かつ実プロセッサが割り当てられていない非実行中の状態にある仮想プロセッサを優先的に選択する選択手段と、
   前記選択手段によって選択された仮想プロセッサに実プロセッサを割り当てるプロセッサ割り当て手段とを具備する
   ことを特徴とする計算機システム
2. 前記仮想計算機マネージャは、
   前記複数の仮想プロセッサのうちのいずれかの仮想プロセッサが前記目的の実行対象に関するスピンロックの取得に失敗したことを検出する検出手段と、
   スピンロックの取得に失敗したことが前記検出手段によって検出された場合、前記選択手段を呼び出す手段とを更に具備し、
   前記選択手段は、スピンロックの取得に失敗したことが前記検出手段によって検出された場合、前記スピンロック変数参照・書き換え手段を用いて前記ゲストＯＳ内のスピンロック変数を取得して、当該スピンロック変数に基づき、前記取得に失敗したスピンロックを所有する仮想プロセッサを特定することにより、前記取得に失敗した前記スピンロックを取得していて、かつ前記非実行中の状態にある仮想プロセッサを優先的に選択する
   ことを特徴とする請求項１記載の計算機システム。
3. 前記選択手段は、前記取得に失敗した前記スピンロックを取得していて、かつ前記非実行中の状態にある仮想プロセッサが存在しない場合、前記取得に失敗した前記スピンロックの待ち状態になく、かつ前記非実行中の状態にある仮想プロセッサを選択することを特徴とする請求項２記載の計算機システム。
4. 前記仮想計算機マネージャは、前記仮想プロセッサによって取得されているスピンロックが解放される際に前記選択手段を呼び出す手段を更に具備し、
   前記選択手段は、スピンロックが解放される際には、任意のスピンロックを取得していて、スピンロック待ちでなく、かつ前記非実行中の状態にある仮想プロセッサを優先的に選択する
   ことを特徴とする請求項１記載の計算機システム。
5. 前記選択手段は、スピンロックが解放される際に選択すべき仮想プロセッサの候補が複数存在する場合、その時点において最も多くのスピンロックを取得している仮想プロセッサを選択することを特徴とする請求項４記載の計算機システム。
6. 前記仮想計算機マネージャは、前記複数の仮想プロセッサ各々のスピンロックの取得状況を保持する、前記仮想計算機マネージャに設けられたスピンロック取得状況保持手段とを更に具備し、
   前記インターフェイスは、前記ゲストＯＳの前記スピンロックアドレス通知手段から呼び出されることにより、前記目的の実行対象に関するスピンロックに対応するスピンロック変数が格納されている前記メモリ上の前記スピンロックアドレスを前記仮想計算機マネージャに通知するのに用いられ、
   前記スピンロック変数参照・書き換え手段は、前記インターフェイスを用いて通知されたスピンロックアドレスに基づき当該アドレスによって指定されるスピンロック変数を参照することにより、当該スピンロック変数の値を取得し、
   前記選択手段は、前記スピンロック変数参照・書き換え手段によって取得されたスピンロック変数の値及び前記スピンロック取得状況保持手段によって示される前記複数の仮想プロセッサ各々のスピンロックの取得状況に基づいて仮想プロセッサを選択する
   ことを特徴とする請求項１記載の計算機システム。
7. 前記仮想計算機マネージャは、前記プロセッサ割り当て手段による実プロセッサ割り当てに応じて前記スピンロック取得状況保持手段に保持されている対応する仮想プロセッサのスピンロック取得状況を更新する更新手段を更に具備することを特徴とする請求項６記載の計算機システム。

Images