JP4620871B2 - マルチスレッドコンピュータシステムにおけるモニタ変換 - Google Patents

Description

【０００１】
【発明の属する技術分野】
概して、本発明は、オブジェクトベースのコンピュータシステムにおいてライトウェイトモニタからヘビーウェイトモニタへ変換（変更）するための方法および装置に関するものである。より詳細には、本発明は、オブジェクトベースのコンピュータシステムにおいて、競合オブジェクトと関連付けられたライトウェイトモニタを、対応するヘビーウェイトモニタへアトミックな(atomically)に変換する方法と装置に関するものである。
【０００２】
【従来の技術】
オブジェクトベースの環境において、スレッドはしばしばサービスの要求を満たすために使用される。スレッドは資源の記憶領域の「スケッチパッド」のようなものと考えてもよく、本質的には、コンピュータシステム内における制御の１つの連続した流れである。一般に、１スレッド、即ち１つの制御のスレッドは、中央処理装置（ＣＰＵ）の一連の指示、または、独立して実行され得るプログラム言語の命令文である。各スレッドは、メソッドの起動が存在する固有の実行スタックを有する。当業者には周知のように、メソッドがスレッドに対して起動される場合、起動はスレッドの実行スタック上に「プッシュ」される。そのメソッドが戻ってきた時、または起動されなかった時、起動は実行スタックから「ポップ」される。１メソッドの起動が他のメソッドを起動し得るため、実行スタックは先入れ後出し方式で動作する。
【０００３】
オブジェクトベースのプログラムの実行中において、１スレッドは複数のオブジェクトを含む処理を実行しようとするかもしれない。一方、複数のスレッドが１つのオブジェクトを含む処理を実行しようとするかもしれない。特定のオブジェクトをいずれかの時間に含む複数の処理、即ち同期処理のうちの一つを起動することができるのは、一つのスレッドだけであることがしばしばある。つまり、唯一のスレッドがある時間に特定のオブジェクトに関する同期処理を実行することが許可される。同期処理、即ち同期メソッドは以下のことを要求する点でブロック構造である。それは、メソッドを呼び出したスレッドが、メソッドが呼び出されたオブジェクトと共に、最初の同期を行い、メソッドが戻ってきた場合オブジェクトに対して非同期となる。１スレッドを１オブジェクトと同期する場合、一般にオブジェクトに対するアクセスの制御を、メソッドを呼び出す前に同期構造を使用して行うことが要求される。
【０００４】
ロック、ミューテック、セマフォ、及びモニタといった同期構造は、共有資源に関する処理をスレッドに許可することが不適切である期間中において、共有資源へのアクセスを制御するために使用される。実例として、１以上のスレッドが任意の特定の時間に１オブジェクトを処理することを防ぐために、オブジェクトはしばしばロックされる。ロックは、オブジェクトのロックの所有権を有している唯一のスレッドに対して、そのオブジェクトにメソッドを実行することを許可するように行われる。
【０００５】
典型的に、スレッドが首尾よくオブジェクトのロックを取得することができた場合、スレッドはオブジェクトの同期処理を実行することを許可される。１スレッドが１オブジェクトのロックを有している間、他のスレッドはオブジェクトに対して付加的な同期処理を実行しようとすることが許可されるかもしれない。また、オブジェクトに対して、非同期処理を実行するかもしれない。スレッド同期はスレッドによる１プロセスであり、それは、オブジェクトのロックを有している唯一のスレッドがロックされたオブジェクト上で同期処理を実行している間、オブジェクトがロックされているか否か、オブジェクトの状態をチェックするために相互に影響している。スレッド同期はまたスレッドにオブジェクトロックを取得させたり取り外したりすることを可能とする。
【０００６】
スレッドが同期している場合、オブジェクトロックを所有する唯一のスレッドが、ロックされたオブジェクトに対し処理を許可されたことを確認するために、同期構造が一般的に提供される。従来の技術においてこのような同期構造の１つがモニタとして知られている。典型的に、モニタは、ミューテックのような低レベルの原始的な同期を使用することにより実行される。たとえプログラムがどんなオブジェクトに対してもモニタ処理を実行できるとしても、一般に全てのオブジェクトに対するモニタの実装を含めることは多くの空間を必要とし非能率的である。このような同期構造がモニタといわれている。一般に、モニタは、１つのオブジェクトと関連付けられたモニタを有するスレッドだけがそのオブジェクトに対し同期処理を実行可能とするように構成されている。モニタはライトウェイトかヘビーウェイトかのいずれかである。典型的に、ライトウェイトモニタは競合を条件としないオブジェクトに対して適している。一方、ヘビーウェイトモニタは競合モニタ処理を取り扱うために使用されるのが望ましい。
【０００７】
ライトウェイトモニタの１つの特定の実施例が「軽いロック：Ｊａｖａ用軽量同期」デビッドＦ．ベーコン他著（１９９８年）（"Thin Locks: Featherweight Synchronization for Java" by David F. Bacon et al）の２５８−２６８ページで説明されており、これ全体を援用する。説明のように、ライトウェイトモニタは、ビットで形成され、それはスレッドＩＤの形式でどのスレッドがライトウェイトモニタを所有し、関連するオブジェクトをロックしているかを識別するためのオブジェクトヘッダを確保する。典型的に、ライトウェイトモニタは競合を条件としないオブジェクトに使用される。例えば、wait、notify、notifyALLという処理はこれらのオブジェクト上では実行されない。図１Ａは、オブジェクトヘッダ１００及び関連するライトウェイトモニタ１０２を示す。ライトウェイトモニタ１０２はスレッドの識別フィールド１０４を含み（所有者フィールドともいう）、ライトウェイトモニタ１０２を所有するスレッドのスレッドＩＤを含んでいる。ライトウェイトモニタ１０２は、再帰カウンタ１０６も含み、これは、現在のスレッドがライトウェイトモニタに再エンターした回数を示している。ライトウェイトモニタ１０２は、ヘビーウェイトモニタフラグが０にセットされた時に、ライトウェイトモニタ１０２をライトウェイトモニタとして認識するために使用されるヘビーウェイトモニタフラグ１０８を含む。
【０００８】
所有者フィールド１０４がゼロの状態において、ライトウェイトモニタ１０２は所有されず、アンロックされる。しかしながら、所有者フィールド１０４が、ライトウェイトモニタ１０２を所有する現在のスレッドを表すスレッドＩＤを含む場合にはそうではない。
【０００９】
ライトウェイトモニタにエンターするために、スレッド１１０は、ライトウェイトモニタ１０２を含むオブジェクトヘッダ１００に対して典型的な比較及びスワップ処理を実行する。比較及びスワップ処理において、比較及びスワップオペレータの新たな値は、スレッド１１０と関連付けられたスレッドＩＤであり、比較及びスワップオペレータのコンペランド(comperand)はゼロである。この構成により、仮に比較及びスワップ処理が成功した場合、ライトウェイトモニタ１０２のスレッドＩＤ、再帰カウンタ及び全てのフラグ（ヘビーウェイトモニタフラグ１０８など）は、初めから全てゼロであり、それは、ライトウェイトモニタ１０２が所有されておらず、よってアンロックされているということを示す。比較及びスワップ処理が首尾よく完了した後、所有者フィールド１０４は、スレッド１１０と関連付けられたスレッドＩＤを含んでいる。このことは、このスレッド１１０が、ライトウェイトモニタ１０２を所有し、ライトウェイトモニタ１０２がロックされているということを示すものである。
【００１０】
スレッドがすでに所有しているモニタ（例えば、スレッドがリエントラントである場合）に、再エンターするような場合には、再エンターしているスレッドは、オーバフローの状態を引き起こすことなく、再帰カウンタ１０６をまず増分させなければならない。再エンターしているスレッドがオーバフロー状態を引き起こす場合、この再エンターしているスレッドはライトウェイトモニタ１０２を、システムモニタ１１６上に生成されているヘビーウェイトモニタ１１４に変換させなければならない。設計により、システムモニタ１１６の現在の所有者のみが、ライトウェイトモニタ１０２をヘビーウェイトモニタ１１４に変換することができることを留意されたい。典型的に、この変換はオブジェクトヘッダ１００に対して、新たに生成されたヘビーウェイトモニタ１１４に対応するヘビーウェイトモニタポインタが比較及びスワップオペレータの新たな値となり、それと共に比較とスワップ処理が実行されることによって遂行される。このように、比較及びスワップ処理の成功後、オブジェクトヘッダ１００はヘビーウェイトモニタポインタを含む。
【００１１】
ヘビーウェイトモニタ１１４は、特定のスレッドがシステムモニタ１１６に再エンターするたびに毎回更新される再帰カウンタフィールド１１８を含む。ヘビーウェイトモニタ１１４はさらに、ヘビーウェイトモニタ所有者フィールド１２０も含む。システムモニタ１１６は、システムモニタ１１６の現在の所有者を表すシステムモニタ所有者フィールド１２２を含む。システムモニタ１１６はさらに、enter、exit、wait、及びnotifyといった特定のスレッドの処理を実行するように構成されている。ライトウェイトモニタ１０２の現在の所有者（即ち、スレッド１１０）は、ライトウェイトモニタ１０２からヘビーウェイトモニタ１１４へ変換することが可能な唯一のスレッドであり、ヘビーウェイトモニタ１１４及び埋め込まれたシステムモニタ１１６の所有者は同一、即ちスレッド１１０でなければならない。
【００１２】
ここで、図１Ｂを参照し、第２のスレッド１２４が、スレッド１１０の現在所有するライトウェイトモニタ１０２にエンターしようとしていると仮定する。前述の通り、スレッド１２４は比較及びスワップ処理を実行することによりライトウェイトモニタ１０２にエンターしようとする。しかしこの場合、比較及びスワップ処理は失敗となる。その理由は、所有者フィールド１０４がスレッド１１０に対応するスレッドＩＤを含んでおり、スレッド１１０がライトウェイトモニタ１０２を所有していることを示しているからである。この時点において、スレッド１２４とスレッド１１０の間において、ライトウェイトモニタ１０２の所有権に対しての競合が生じる。システムモニタ１１６の所有者としてのスレッド１１０のみが、ライトウェイトモニタ１０２からヘビーウェイトモニタ１１４へ変換することが可能なので、スレッド１２４はライトウェイトモニタ１０２がスレッド１１０により開放されるまでの間、スピンロックループにエンターする。スピンロックループによって、スレッド１１０がライトウェイトモニタ１０２をアンロックするまでの間、スレッド１２４は待ち行列にエンターすることを意味する。従来の技術では公知のように、一般にスピンロックは、システム資源の非能率的な使用となる部分において望ましくない結果である。スピンロックは、ライトウェイトモニタ１０２が長時間ロックされることにより、ライトウェイトモニタ１０２がスピンロックされるまで他のスレッドをwaitさせることを引き起こすという場合において、とりわけ非能率的である。さらに、優先度の高いスレッドと低いスレッドが共にライトウェイトモニタ１０２に関してスピンロックされるような状況において、優先度の低いスレッドが「待ちわびた(starving)」状態となる可能性がある。
【００１３】
従って、求められているものは、オブジェクトベースシステムにおけるモニタの競合を解決するための効果的な方法および装置である。
【００１４】
【発明の概要】
概して、本発明は、競合オブジェクトに関連付けられたライトウェイトモニタを効率的にヘビーウェイトモニタへ変換するための改良された方法、装置、およびコンピュータシステムに関する。発明の一側面によると、第２のスレッドによって所有されるオブジェクトに関して同期処理を実行するための第１のスレッドに対して、第１のスレッドは新たなヘビーウェイトモニタを生成し、第２のスレッドを新たに生成されたヘビーウェイトモニタの所有者に設定する。そして、第１のスレッドはヘビーウェイトモニタにエンターする。こうすれば、第２のスレッドがオブジェクトをアンロックするまで、第１のスレッドがスピンロックを行う必要がない。
【００１５】
本発明は、方法、コンピュータシステム、および装置を含む種々の形態にて実施され得る。本発明のいくつかの実施の形態が以下に説明される。方法および装置が開示されている。本発明の一側面によれば、第２のスレッドによって所有されるオブジェクトが第１のスレッドに対して利用不能であるときに、ライトウェイトモニタをヘビーウェイトモニタへ変換するためのコンピュータで実行される方法は、ライトウェイトモニタに関連付けられたオブジェクトの所有権を決定する工程を含む。仮に第２のスレッドが該当オブジェクトを所有することが判断された場合、第１のスレッドは新たにヘビーウェイトモニタを生成する。そして、第１のスレッドは、第２のスレッドを新たに生成されたヘビーウェイトモニタの所有者として設定する。次に、第１のスレッドは新たなヘビーウェイトモニタにエンターする。
【００１６】
本発明の更に別の側面によれば、コンピュータシステムは、メモリおよび複数のスレッドを含む。また、コンピュータシステムは、メモリに結合されたプロセッサ、およびオブジェクトヘッダを含むオブジェクトを含み、同オブジェクトヘッダはオブジェクトの所有権に関連する情報を含むライトウェイトモニタを含むように構成される。第１のスレッドＩＤによって指示されたようにオブジェクトをロックしていた、複数のスレッドから選択された第１のスレッドは、ライトウェイトモニタに含まれ、複数のスレッドから選択された第２のスレッドは、オブジェクトが第２のスレッドに対して利用可能である場合、ライトウェイトモニタを対応する第１のスレッドによって所有されたヘビーウェイトモニタに変換するように構成されている。
【００１７】
発明の更に別の側面によれば、ライトウェイトモニタを含むオブジェクトヘッダを有するオブジェクトに関する同期処理の実行を第１のスレッドが試行する場合、ライトウェイトモニタをヘビーウェイトモニタに変換するコンピュータプログラム製品が開示されている。
【００１８】
コンピュータプログラム製品は、オブジェクトの所有権を決定するとともに、第２のスレッドによってオブジェクトが所有されていると判断される場合にヘビーウェイトモニタを生成し、ヘビーウェイトモニタを第２のスレッドに設定するとともに、第１のスレッドをヘビーウェイトモニタにエンターさせるコンピュータコードと、同コンピュータコードを格納するためのコンピュータ読み取り可能な記録媒体とを含む。
【００１９】
本発明のこれら及び他の利点は、以下の詳細な説明を読み、種々の図面を調べることにより明らかになるであろう。
【００２０】
【発明の実施の形態】
マルチスレッドのオブジェクトベースコンピュータシステムにおいて、一般に、２以上のスレッドが任意の特定時間に１つのオブジェクトに関する処理を行うことを防止することができるように、オブジェクトは同期構造を備える。
【００２１】
本発明で示される一実施の形態においては、広くライトウェイトモニタを用いるシステムが意図されている。第２のスレッドによって既に所有されているライトウェイトモニタへ第１のスレッドがエンターしようとする場合、第１のスレッドはヘビーウェイトモニタを生成し、第２のスレッドをその新たに生成されたヘビーウェイトモニタの所有者として設定する。その後、第１のスレッドは新たに生成されたヘビーウェイトモニタにエンターする。このように、第１のスレッドは、第２のスレッドがライトウェイトモニタを開放するまでwaitすることはない。
【００２２】
図２は、本発明の実施の形態に従って、第１のスレッドがオブジェクトの所有権を得るプロセス２００を詳しく図示したフローチャートである。プロセス２００は、オブジェクトが現在所有されているか否かの判断によって２０２から開始する。実施例において、オブジェクトヘッダは、所有者フィールドを有するライトウェイトモニタおよびヘビーウェイトモニタフラグを含む。所有者フィールドがゼロであれば、該オブジェクトは非所有であり、それ以外ではオブジェクトは、スレッドによって所有される。そのスレッドのスレッドＩＤは、所有者フィールドに格納されている。仮に、オブジェクトが所有されていないと判断された場合、２０４において、要求しているスレッドは、当該オブジェクトに関連付けられたライトウェイトモニタの所有者フィールドに自身のスレッドＩＤを入力することによりオブジェクトの所有権を得る。
【００２３】
しかしながら、２０２において、オブジェクトが所有されていると判断された場合、オブジェクトヘッダの内容が２０６において評価される。オブジェクトヘッダが、第１のスレッドのスレッドＩＤを所有者フィールドに格納するライトウェイトモニタを含む場合には、第１のスレッドが当該オブジェクトに関連付けられたライトウェイトモニタを現在所有している。この場合、第１のスレッドはリエントラントとして参照される。リエントラントであることによるオブジェクトの現在の所有者としての意味は、第１のスレッドがオブジェクトに関連付けられたライトウェイトモニタに再エンターを試行することである。そのような状況は、例えば、スレッドがオブジェクトを開放し、いくらか時間が経過した後に、関連するライトウェイトモニタに再エンターすることによりオブジェクトを再取得する際に生じる。一旦、第１のスレッドが現在のスレッドであると判断されれば、２０８において、第１のスレッドはライトウェイトモニタに含まれる再帰カウンタを増分することによりライトウェイトモニタに再エンターする。
【００２４】
しかしながら、２０６において、オブジェクトヘッダがヘビーウェイトモニタに対応するヘビーウェイトモニタポインタを含む場合、２１０において第１のスレッドは対応するヘビーウェイトモニタにエンターする。
【００２５】
しかしながら、２０６において、オブジェクトヘッダが第１のスレッドとは異なる第２のスレッドに対応するスレッドＩＤを含む場合、ライトウェイトモニタは第２のスレッドによって所有されている。この状況では、当該オブジェクトの所有権に関して、第１のスレッドと第２のスレッドとの間には競合が存在する。本発明の実施の形態では、上記２つのスレッド間の競合を解決するために、第１のスレッドは新たなヘビーウェイトモニタを生成し、２１２において、新たに生成されたヘビーウェイトモニタの所有者を第２のスレッドに設定する。このように、２１０において、第２のスレッドが当該オブジェクトに関連付けられたライトウェイトモニタを開放するまでwaitすることなく、第１のスレッドは新たに生成されたヘビーウェイトモニタにエンターすることができる。この方法では、オブジェクトの所有権に関する第１のスレッドおよび第２のスレッド間の競合は、例えば、ライトウェイトモニタが開放されるまで第１のスレッドをスピンロックする必要なく解決される。
【００２６】
しかしながら、第１のスレッドがヘビーウェイトモニタを生成するためには、第１のスレッドは新たに生成されたヘビーウェイトモニタに埋め込まれたシステムモニタをまず所有しなければならないことに留意されたい。しかしながら、ライトウェイトモニタからヘビーウェイトモニタへの変換を行うスレッドは、ライトウェイトモニタの所有者である必要がないため、新たに生成されたヘビーウェイトモニタの所有権を第２のスレッドに設定することによって、衝突が起こる可能性が生じる。例として、仮に第１のスレッドがライトウェイトモニタを第２のスレッドによって所有されるヘビーウェイトモニタに変換する場合、システムモニタは第１のスレッドによって所有され、ヘビーウェイトモニタは第２のスレッドによって所有される。この衝突は、２１２において新たに生成されるヘビーウェイトモニタに含まれるリーエンホルダ(lienholder)フィールドおよびリーエンホルダ再帰フィールドの導入によって解決される。実施例において、リーエンフィールドは、ヘビーウェイトモニタへと変換されたライトウェイトモニタの所有者として第２のスレッドを認識する。
【００２７】
図３Ａは、本発明の一実施の形態に従うヘビーウェイトモニタ３００を図示する。ヘビーウェイトモニタ３００は、システムモニタ所有者フィールド３０４を含むシステムモニタ３０２上に構築される。ヘビーウェイトモニタは、所有者フィールド３０６および再帰カウンタフィールド３０８を含む。実施例において、ヘビーウェイトモニタ２００は、またリーエンフィルダ３１０およびリーエンフィルダ再帰フィールド３１２を含む。リーエンフィルダフィールド３１０およびはリーエンフィルダ再帰フィールド３１２は、ヘビーウェイトモニタから変換されたライトウェイトモニタの所有者および再帰カウントを一時的に保持するために使用される。
【００２８】
例として、図３Ｂは、図２のブロック２１２において、第１のスレッドによって生成された場合のヘビーウェイトモニタ３００を図示する。第１のスレッドがシステムモニタ３０２を所有するため、システムモニタ所有者フィールド３０４は、第１のスレッドのスレッドＩＤを含む。一方、第２のスレッドのスレッドＩＤは、ヘビーウェイトモニタ所有者フィールド３０６に格納される。第２のスレッドがヘビーウェイトモニタ３００から生成されたライトウェイトモニタを所有していたため、ヘビーウェイトモニタ３００の真の所有者は第２のスレッドであり、第１のスレッドではない。好ましい実施の形態では、リーエンフィールド３１０は、第２のスレッドのスレッドＩＤを含み、それによりヘビーウェイトモニタ３００の真の所有者の識別情報を保存する。
【００２９】
図４は、本発明の一実施の形態に従って、第１のスレッドがオブジェクトの所有権を得るプロセス４００である。プロセス４００は、プロセス２００のとり得る実施の形態のほんの一例にすぎず、４０２において、オブジェクトが所有されているかを第１のスレッドによって判断することによって開始することに留意されたい。実施例において、オブジェクトの所有権は、オブジェクトヘッダに含まれるライトウェイトモニタに対してアトミックなコンペアアンドスワップ処理を実行することによって判断される。上述したように、アトミックなコンペアアンドスワップ処理は、コンペランド(comperand)値が「０」を示すため、成功したコンペアアンドスワップ処理ではオブジェクトが非所有であり、ライトウェイトモニタ内の全てのデータフィールドが「０」を示す。
【００３０】
４０４において、仮に、アトミックなコンペアアンドスワップ処理が成功であると判断された場合、オブジェクトは非所有であったことになり、現在は第１のスレッドによって所有されていることになる。しかしながら、アトミックなコンペアアンドスワップ処理が成功しなかったと判断された場合、ライトウェイトモニタの少なくとも１つのフィールドはゼロではなかったことになる。この場合、４０６において、比較およびスワップ処理が失敗した理由を判断するためにオブジェクトヘッダの評価が行われる。
【００３１】
４０６において、オブジェクトヘッダが第１のスレッドのスレッドＩＤを含むライトウェイトモニタを含む場合、第１のスレッドがライトウェイトモニタの現在の所有者であり、それにより第１のスレッドはリエントラントであると考慮される。この場合、４０８における判断は、ライトウェイトモニタに含まれる再帰カウンタの増分がオーバーフロー状態を招く結果となるか否かによってなされる。再帰カウンタの増分がオーバーフロー状態を招く結果とならない場合、４１０において、ライトウェイトモニタの再帰カウンタは適切に増分される。一旦、増分カウンタが適切に増分された場合、一実施の形態において、４１２において、第１のスレッドは、増分された再帰カウンタのアトミックなコンペアアンドスワップをオブジェクトヘッダに対して実行することによってライトウェイトモニタに再エンターする。
【００３２】
４０８に戻り、再帰カウンタの増分がオーバーフロー状態を招く結果となる場合、４１４において、第１のスレッドは新たなヘビーウェイトモニタを生成する。
【００３３】
４０６に戻り、オブジェクトヘッダが、現在第１のスレッドとは異なる第２のスレッドによって所有されているライトウェイトモニタを含む場合、４１４において、第１のスレッドは新たなヘビーウェイトモニタを生成する。４１６において、リーエンホルダは、現在のライトウェイトモニタの所有者（例えば、第２のスレッド）に設定され、リーエンホルダ再帰カウンタは現在の再帰カウンタに設定される。そして、４１８において、アトミックなコンペアアンドスワップ処理が実行される。この方法によれば、新たに生成されたヘビーウェイトモニタに対応するヘビーウェイトモニタポインタはオブジェクトヘッダに挿入される。仮に、４２０において、アトミックなコンペアアンドスワップ処理が成功ではないと判断された場合、新たに生成されたヘビーウェイトモニタは４２２において削除され、新たなヘビーウェイトモニタが４１４において生成される。アトミックなコンペアアンドスワップ処理は、例えば、アトミックなコンペアアンドスワップ処理が行われる前に、第３のスレッドがヘビーウェイトモニタの所有権を取得した場合に失敗することがある。
【００３４】
しかしながら、アトミックなコンペアアンドスワップ処理が成功した場合、４２４において、第１のスレッドは、オブジェクトヘッダ内に含まれるヘビーウェイトモニタポインタに対応するヘビーウェイトモニタに埋め込まれたシステムモニタにエンターする。この時点で、第１のスレッドは、オブジェクトヘッダ内に含まれたヘビーウェイトモニタポインタに対応するヘビーウェイトモニタに埋め込まれたシステムモニタへのエンターを果たす。しかしながら、今、システムモニタ所有者およびヘビーウェイトモニタ所有者が１つで、かつ同一であることを確かにする必要がある。
【００３５】
図５は、本発明の一実施の形態に従って、第１のスレッドがヘビーウェイトモニタにエンターするプロセス５００を詳しく図示したフローチャートである。プロセス５００は、プロセス４００の４２４へエンターする一実施の形態であることに留意されたい。より詳しくは、プロセス５００は、リーエンホルダが存在するか否かの判断がなされる５０２において開始する。一実施の形態において、リーエンホルダが存在するか否かの判断は、リーエンホルダフィールドが非ゼロの値を含むかどうかの判断によって遂行される。リーエンホルダフィールドが「０」である場合、リーエンホルダは存在せず、それ以外の場合にはリーエンホルダは、リーエンホルダフィールドに含まれるスレッドＩＤによって示されるスレッドである。リーエンホルダが存在しない場合（例えば、リーエンホルダフィールドがゼロである）、ヘビーウェイトモニタの所有者フィールドは現在のスレッドＩＤに設定され、ヘビーウェイト再帰カウンタは、５０４において１だけ増分された現在の再帰カウンタに設定される。再帰カウンタは、システムモニタへのエンターを補償するために増分される。
【００３６】
しかしながら、５０２において、リーエンホルダが存在すると判断された場合、５０６において、リーエンホルダが現在のスレッドであるか否かの判断がなされる。一実施の形態において、リーエンホルダの識別は、リーエンホルダフィールドの内容を読むこと、および同フィールドに含まれるスレッドＩＤを判断することによて遂行される。仮に、現在のスレッドがリーエンホルダスレッドではない場合、５０８において、システムwaitを呼び出すことにより、リーエンホルダスレッドに対してモニタ所有者を譲らなければならない。リーエンホルダスレッドがモニタ所有者を取り戻した後、現在のスレッドはリーエンホルダスレッドによって立ち上げられることになる。
【００３７】
５０６において、現在のスレッドがリーエンホルダであると判断された場合、５１０において、ヘビーウェイトモニタが更新される。一実施の形態において、ヘビーウェイトモニタは現在のリーエンホルダフィールドを「０」に再設定することによって更新される。また、ヘビーウェイトモニタの更新は、ヘビーウェイトモニタの所有者フィールドを現在のスレッドに対応するスレッドＩＤに設定することを含む。実施例において、リーエンホルダ再帰フィールドは、現在のモニタエンター処理を考慮して１だけ増分される。そして、増分されたリーエンホルダ再帰フィールドがゼロにリセットされた後に、ヘビーウェイトモニタ再帰フィールドは、リーエンホルダフィールドの増分された値に設定される。ヘビーウェイトモニタが更新された後、５１２において、システムモニタはnotifyALLを広める。notifyALLは、５０８において、待ち行列に含まれるスレッドを立ち上げる。そして、それらスレッドは、５０２へ戻ることによって更なる処理のために行列にwaitする。
【００３８】
図６は、本発明の一実施の形態に従う、エンターモニタ機能５００および種々の他のモニタ機能の関係６００を図示する。実施例において、所有者確認機能６０２は、現在のスレッドがヘビーウェイトモニタを所有することを確実とする。仮に、所有者確認機能６０２が、現在のスレッドがヘビーウェイトモニタを所有していないと判断した場合、エラーメッセージが呼び出され、それ以外の場合には、所有者確認機能は成功し、制御が選択されたモニタ機能へ渡される。そのようなモニタ機能は、６０４におけるwait、６０６におけるexit、そして６０８におけるnotify（または、notifyALL）を含む。
【００３９】
図７は、本発明の一実施の形態に従って、所有者確認機能７００を詳しく図示したフローチャートである。所有者確認機能７００は、所有者確認機能６０２のとり得る実施の形態の一例にすぎないことに留意されたい。より詳しくは、所有者確認機能７００は、現在のスレッドがヘビーウェイトモニタを所有するかを判断することによって７０２から開始する。現在のスレッドがヘビーウェイトモニタを所有している場合、ヘビーウェイトモニタ所有者が確かめられる。しかしながら、現在のスレッドがヘビーウェイトモニタを所有していない場合、７０４において、現在のスレッドがリーエンホルダであるかが判断される。仮に、現在のスレッドがリーエンホルダではない場合、エラーメッセージが渡され、それ以外の場合には、７０６においてスレッドがヘビーウェイトモニタにエンターする。一実施の形態において、７０６へのエンターは、４２４へのエンターとして実施されていることに留意されたい。一旦、現在のスレッドが首尾よくヘビーウェイトモニタにエンターした場合、再帰カウンタが７０６へのエンターを考慮して減少される。この時点において、ヘビーウェイトモニタの所有権は確かめられる。
【００４０】
図８は、本発明の一実施の形態に従うモニタwait処理８００を詳しく図示したフローチャートである。モニタwait処理８００は、モニタwait処理６０４のとり得る実施の形態の一例である。モニタwait処理８００は、６０２における所有者確認機能が成功した後にのみ開始することに留意されたい。より詳しくは、モニタwait処理８００は、現在の所有者および再帰カウントを保存することによって８０２から開始する。一旦、保存されると、８０４において、所有者および再帰カウントはゼロに設定され、モニタを非所有に設定する。一旦、モニタが非所有となると、８０６において、ヘビーウェイトモニタを開放するシステムモニタwaitが呼ばれる。一旦、システムモニタwaitが、notifyまたはnotifyALLの発行によって完了すると、例えば、８０８において、現在のヘビーウェイトモニタの所有者の認識情報が再設定される。一実施の形態において、認識情報は、８０２において保存された現在の所有者および現在の再帰を検索し、ヘビーウェイトモニタの現在の所有者フィールドおよび現在の再帰フィールドのそれぞれに入力することによって再設定される。
【００４１】
図９は、本発明の一実施の形態に従うexit機能９００を詳しく図示したフローチャートである。exit機能９００は、exit機能６０６のとり得る実施の形態の一例であることに留意されたい。より詳しくは、exit機能９００は、現在のスレッドがヘビーウェイトモニタの所有者であるかを判断することによって９０２から開始する。仮に、現在のスレッドがヘビーウェイトモニタの所有者である場合、９０４において、再帰レベルが１であると判断される。仮に、再帰レベルが１である場合、所有者フィールドは「０」に設定され、再帰カウントは「０」に設定され、そして９０６において、システムモニタはexitする。しかしながら、仮に、９０４において、再帰カウントが「１」ではなかったと判断された場合、９０８において、再帰カウンタは減少され、システムモニタはexitする。何れの場合においても、exit機能は首尾よく行われる。
【００４２】
９０２に戻り、仮に、現在のスレッドがヘビーウェイトモニタの所有者ではない場合、９１０において、現在のヘビーウェイトモニタ所有者がリーエンホルダであるかの判断が行われる。そうではない場合、エラーメッセージが呼ばれる。一実施の形態において、容認し難いが対応するエンター処理がないままにexitが呼ばれる。しかしながら、仮に、現在のヘビーウェイトモニタ所有者がリーエンホルダである場合、９１２において、リーエンホルダスレッドはヘビーウェイトモニタにエンターする。実施例において、９１２におけるエンターは、４１４におけるエンターとして実施されている。一旦、リーエンホルダスレッドが首尾よくヘビーウェイトモニタにエンターすると、再帰カウンタは、９１２におけるエンターを補償するために減少される。この時点において、exit機能は首尾よく行われる。
【００４３】
図１０は、本発明の一実施の形態に従うnotify（または、notifyALL）機能１０００を詳しく図示したフローチャートである。notify（または、notifyALL）機能１０００は、notify（または、notifyALL）機能６０８のとり得る実施の形態の一例である。notify（または、notifyALL）機能１０００は、６０２における所有者確認機能が首尾よく行われた後のみに開始する。より詳しくは、notify（または、notifyALL）機能１０００は、システムモニタ上のnotify（または、notifyALL）を呼び出して１００２から開始する。
【００４４】
図１１は、本発明を実施するのに好適な、一般的な汎用コンピュータシステム１１００を図示する。コンピュータシステム１１００は、主記憶装置１１０４（一般に、読み出し専用メモリ、即ちＲＯＭ）、または主記憶装置１１０６（一般に、ランダムアクセスメモリ、即ちＲＡＭ）を含む記憶装置に結合された任意の数のプロセッサ１１０２（また中央処理装置として参照される、即ちＣＰＵ）を含む。
【００４５】
コンピュータシステム１１００、即ちより詳しくはＣＰＵ１１０２は、当業者によって認識されるように、仮想マシンをサポートするように構成されてもよい。コンピュータシステム１１００でサポートされる仮想マシンの一例を、図７を参照して以下に説明する。当業者に公知のように、ＲＯＭは一般にデータおよび命令を単方向にてＣＰＵ１１０２へ転送するように動作するのに対して、ＲＡＭは一般にデータおよび命令を双方向にて転送するために使用される。主記憶装置１１０４，１１０６の双方は、任意の好適なコンピュータ読み出し可能な記録媒体を含んでもよい。一般に、大容量の装置である補助記憶媒体１１０８もまたＣＰＵ１１０２と双方向で結合され、付加的なデータ記憶容量を提供する。大容量記憶装置１１０８は、コンピュータコード、データなどを含むプログラムを格納するために使用されてもよい。一般に、大容量記憶装置１１０８は、主記憶装置１１０４，１１０６よりも一般に低速なハードディスク、またはテープのような記憶媒体である。大容量記憶装置１１０８は、磁気または紙テープリーダあるいは何らかの公知の装置の形態をとってもよい。大容量記憶装置１１０８に格納される情報は、適切な場合において、仮想メモリとしてＲＡＭ１１０６の一部とするような標準的な方法にて組み込まれてもよい。ＣＤ−ＲＯＭのような具体的な主記憶装置１１０４もまた、単方向にてＣＰＵ１１０２へデータを渡す。
また、ＣＰＵ１１０２は、限定されるわけではないが、ビデオモニタ、トラックボール、マウス、キーボード、マイクロホン、タッチディスプレイ、変換カード読取装置、磁気または紙テープ読取装置、タブレット、スタイラス、音声または手書き文字認識装置、あるいはコンピュータのような他の公知の入力装置などの装置を含む１つ以上の入出力装置１１１０に結合されてもよい。最後に、ＣＰＵ１１０２は、コンピュータまたは遠距離通信ネットワーク、例えば、インターネットネットワークまたはイントラネットネットワークに１１１２に一般的に図示されるネットワーク接続を用いて選択的に結合されてもよい。そのようなネットワーク接続により、上述した方法の工程を実行する過程で、ＣＰＵ１１０２はネットワークから情報を受信したり、あるいはネットワークへ情報を送信するように意図されている。ＣＰＵ１１０２を用いて実行される連続した命令としてしばしば表されるそのような情報は、例えば、搬送波に埋め込まれるコンピュータデータ信号の形態で、ネットワークから受信したり、ネットワークへ送信される。上述した装置および用具は、コンピュータハードウェアおよびソフトウェア分野の当業者にとって周知であろう。
【００４６】
本発明のほんのわずかな実施の形態しか説明していないが、本発明の精神および範囲を逸脱することなく、本発明は他の多くの具体的な形態に実施され得ることを理解されたい。例として、オブジェクトのロックおよびアンロックに関する工程が再整理されてもよい。また、本発明の精神および範囲を逸脱することなく、工程が削除または追加されてもよい。
【００４７】
本発明に従うライトウェイトモニタからヘビーウェイトモニタへ変換する方法は、Java（登録商標）をベースとする環境に関して実施することが特に好適であるが、本方法は、一般にオブジェクトをベースとする任意の環境に適用されてもよい。特に、本方法はプラットフォームに依存しないオブジェクトベースの環境において使用することが好適である。また、本方法は、なんらかの分散型オブジェクト指向システムにおいて実施されてもよいことを認識されたい。
【００４８】
モニタは、オブジェクトがロック状態、非ロック状態、あるいは動作状態であるかを識別するビットとして説明された。一般に、モニタに関するビット数は広範に変更されることを留意されたい。加えて、オブジェクトの状態はモニタ以外の機構を用いて識別されてもよいことを認識されたい。例として、オブジェクトは、オブジェクトの状態を識別するリストへのポインターを含んでもよい。
【００４９】
本発明は、仮想マシンに関連するコンピュータシステムで使用されるものとして説明されたが、一般に、本発明は任意の好適なオブジェクト指向コンピュータシステムに実施されてもよいことを認識されたい。具体的には、本発明に従うオブジェクトのロック、非ロックの方法は、一般に、本発明の精神および範囲を逸脱することなく、任意のマルチスレッドのオブジェクト指向システムに実施されてもよい。従って、これらの例は、限定的ではなく例示的なものとして考慮されるものであり、本発明はここで説明した詳細に限定されるものではなく、添付の請求の範囲の均等物の全範囲内において改変されてもよい。
【図面の簡単な説明】
【図１Ａ】 ライトウェイトモニタからヘビーウェイトモニタへの従来の変換を示した図である。
【図１Ｂ】 競合ライトウェイトモニタを示した図である。
【図２】 本発明の実施の形態に従い、スレッドがオブジェクトの所有権を取得するプロセスを詳述したフローチャートである。
【図３Ａ】 本発明の実施の形態に従い実施されたヘビーウェイトモニタを示した図である。
【図３Ｂ】 ライトウェイトモニタの変換により形成された図３Ａに示すヘビーウェイトモニタを示した図である。
【図４】 図２のプロセスの一実施例について詳述したフローチャートである。
【図５】 本発明の実施の形態に従い、処理がエンタされたモニタを詳述したフローチャートである。
【図６】 本発明の実施の形態に従いファンクションにエンタされたモニタと他の様々なモニタ機能との関係を示した図である。
【図７】 本発明の実施の形態に従い、処理の所有者のチェックについて詳述したフローチャートである。
【図８】 本発明の実施の形態に従い、wait処理８００のモニタについて詳述したフローチャートである。
【図９】 本発明の実施の形態に従い、exit機能について詳述したフローチャートである。
【図１０】 本発明の実施の形態に従いnotifyまたはnotifyALL機能について詳述したフローチャートである。
【図１１】 本発明を実施するのに適当な典型的で一般的な目的のコンピュータシステムを示した図である。
【符号の説明】
１００…オブジェクトヘッダ
１０２…ライトウェイトモニタ
１０４…所有者フィールド
１０６…再帰カウンタ
１０８…ヘビーウェイトフラグ
１１０…スレッド
１１４…ヘビーウェイトモニタ
１１６…システムモニタ
１１８…再帰カウンタ
３００…ヘビーウェイトモニタ
３０２…システムモニタ
３０４…システムモニタ所有者フィールド
３０６…所有者フィールド
３０８…再帰カウンタフィールド
３１０…リーエンフィルダフィールド
３１２…リーエンフィルダ再帰フィールド
１１００…コンピュータシステム
１１０４，１１０６…主記憶装置
１１０８…補助記憶媒体
１１１０…入出力装置

Claims (16)

1. マルチスレッドコンピュータにおいて、ライトウェイトモニタに関連付けられたヘビーウェイトモニタが生成されるときに、モニタ競合を解決するための方法であって、
   第１のスレッドによってオブジェクトヘッダの内容を判定する工程と、
   前記オブジェクトヘッダが、前記第１のスレッドとは異なる第２のスレッドによって現在所有されているライトウェイトモニタを含んでいると判定された場合には、関連付けられたヘビーウェイトモニタのポインタを有する前記第１のスレッドによってヘビーウェイトモニタを生成する工程と、
   前記ライトウェイトモニタの現在の所有権者である前記第２のスレッドを先取得権者として特定する工程と、
   先取得権者再帰カウンターにおける先取得権者再帰カウント数を現在の再帰カウント数に設定する工程と、
   前記ヘビーウェイトモニタポインタを前記オブジェクトヘッダに挿入する工程と、
   前記第１のスレッドによって、前記ヘビーウェイトモニタポインタに対応する前記ヘビーウェイトモニタに埋め込まれているシステムモニタにエンターする工程とを備える方法。
2. 請求項１に記載の方法であって、前記挿入工程は、前記オブジェクトヘッダおよび前記ヘビーウェイトモニタポインタのアトミックなコンペアアンドスワップ処理を実行する工程を備える方法。
3. 請求項２に記載の方法であって、前記アトミックなコンペアアンドスワップ処理が成功しなかったと判断されたとき、
   前記ヘビーウェイトモニタを削除する工程と、
   関連付けられたヘビーウェイトモニタポインタを有する前記第１のスレッドによって新たなヘビーウェイトモニタを生成する工程と、
   先取得権者フィールドの設定にリターンする工程とを更に備える、方法。
4. 請求項１に記載の方法であって、
   前記オブジェクトヘッダが、前記第１のスレッドによって所有されているライトウェイトモニタを含んでいると決定された場合には、前記第１のスレッドが再エンタースレッドとして前記先取得権者再帰カウンターとは異なる再帰カウンタのオーバーフローを引き起こすか否かを決定する工程と、
   前記再帰カウンタがオーバーフローしないときには前記再帰カウンタを増分させる工程と、
   前記増分された再帰カウンタおよび前記オブジェクトヘッダのアトミックなコンペアアンドスワップ処理を実行する工程とを備える、方法。
5. 請求項１に記載の方法であって、前記オブジェクトヘッダが、ヘビーウェイトモニタポインタを含んでいると決定された場合には、前記第１のスレッドによって、前記ヘビーウェイトモニタポインタに対応する前記ヘビーウェイトモニタに埋め込まれているシステムモニタにエンターする工程を更に備える、方法。
6. 請求項１に記載の方法であって、前記システムモニタにエンターする工程は、
   現在のスレッドが先取得権者であるか否かを判定する工程と、
   現在の先取得権者フィールドに第１の値を設定する工程と、
   所有権者フィールドに現在のスレッドＩＤを設定する工程と、
   再帰フィールドに先取得権者の再帰値に第２の値を加えた値を設定する工程と、
   先取得権者再帰フィールドに前記第１の値を再設定する工程とを備える、方法。
7. 請求項１に記載の方法であって、さらに前記システムモニタによってnotifyALLコマンドを発行する工程を備える、方法。
8. 請求項４に記載の方法であって、前記再帰カウンタの増分がオーバーフロー状態を招くと判断されるとき、前記ライトウェイトモニタを対応するヘビーウェイトモニタに変更する工程を備える、方法。
9. 請求項６に記載の方法であって、前記第１の値は０であり、前記第２の値は１である、方法。
10. 第１のスレッドがライトウェイトモニタを含むオブジェクトヘッダを有するオブジェクトに関する同期処理の実行を試みる際に、前記ライトウェイトモニタがヘビーウェイトモニタへ変更されるときに生じるモニタ競合を解決するためのコンピュータプログラムを格納するコンピュータ読み取り可能媒体であって、
    前記コンピュータプログラムは、
    前記第１のスレッドによって、前記オブジェクトヘッダの内容を判定するための機能と、
    前記オブジェクトヘッダが、前記第１のスレッドとは異なる第２のスレッドによって現在所有されるライトウェイトモニタを含んでいると判定された場合に、関連付けられたヘビーウェイトモニタのポインタを有する前記第１のスレッドによってヘビーウェイトモニタを生成するための機能と、
    前記ライトウェイトモニタの現在の所有権者である前記第２のスレッドを先取得権者として特定するための機能と、
    先取得権者再帰カウンターにおける先取得権者再帰カウント数を現在の再帰カウント数に設定するための機能と、
    前記ヘビーウェイトモニタポインタを前記オブジェクトヘッダに挿入するための機能と、
    前記第１のスレッドによって、前記ヘビーウェイトモニタポインタに対応する前記ヘビーウェイトモニタに埋め込まれているシステムモニタにエンターするための機能とを、
    コンピュータによって実現させる、コンピュータ読み取り可能媒体。
11. 請求項１０に記載のコンピュータ読み取り可能媒体において、前記コンピュータプログラムは、前記オブジェクトヘッダおよび前記ヘビーウェイトモニタポインタのアトミックなコンペアアンドスワップ処理を実行するための機能を更にコンピュータによって実現させる、コンピュータ読み取り可能媒体。
12. 請求項１１に記載のコンピュータ読み取り可能媒体において、前記コンピュータプログラムは、前記アトミックなコンペアアンドスワップ処理が成功しない場合、
    前記ヘビーウェイトモニタを削除するための機能と、
    関連付けられたヘビーウェイトモニタポインタを有する前記第１のスレッドによって新たなヘビーウェイトモニタを生成するための機能と、
    先取得権者フィールドの設定にリターンするための機能とを更にコンピュータによって実現させる、コンピュータ読み取り可能媒体。
13. 請求項１０に記載のコンピュータ読み取り可能媒体において、前記コンピュータプログラムは、前記オブジェクトヘッダが、前記第１のスレッドによって所有されているライトウェイトモニタを含むと判定されたときに、
    再エンタースレッドとしての前記第１のスレッドが前記先取得権者再帰カウンターとは異なる再帰カウンタのオーバフローを引き起こすか否かを判定するための機能と、
    前記再帰カウンタがオーバフローしないと判定されたときに前記再帰カウンタを増分するための機能と、
    前記増分された再帰カウンタおよびオブジェクトヘッダのアトミックなコンペアアンドスワップ処理を実行するための機能とを更にコンピュータによって実現させる、コンピュータ読み取り可能媒体。
14. 複数のスレッドを含むメモリを有するコンピュータシステムであって、前記コンピュータシステムは、
    前記メモリに接続されたプロセッサと、
    オブジェクトの所有権に関する情報を含むライトウェイトモニタを含むオブジェクトヘッダを含むオブジェクトと、
    複数のスレッドから選択された第１のスレッドであって、前記オブジェクトが前記第１のスレッドにとって利用不能なとき、前記ライトウェイトモニタを、第２のスレッドによって所有されている対応するヘビーウェイトモニタに変更する第１のスレッドと、
    関連付けられたヘビーウェイトモニタポインタを有する第１のスレッドによってヘビーウェイトモニタを生成する前記ライトウェイトモニタに含まれている第２のスレッドＩＤによって示された前記オブジェクトをロックした複数のスレッドから選択された第２のスレッドと、
    前記ライトウェイトモニタの現在の所有権者である前記第２のスレッドを先取得権者として特定するための先取得権者特定部と、
    先取得権者再帰カウンター内の先取得権者再帰カウント数に現在の再帰カウント数を格納するための先取得権者再帰カウンターと、
    前記ヘビーウェイトモニタポインタに対応する前記ヘビーウェイトモニタに埋め込まれており、前記第１のスレッドがエンターすることによって前記モニタに関する競合を解決する、システムモニタと、
    を備える、コンピュータシステム。
15. 請求項１４に記載のコンピュータシステムであって、前記現在の再帰カウント数は、前記オブジェクトが再エンターした回数を表す、コンピュータシステム。
16. 請求項１５に記載のコンピュータシステムであって、前記ヘビーウェイトモニタポインタは、前記オブジェクトに関連付けられたヘビーウェイトモニタを示す、コンピュータシステム。

Images