JPWO2013175858A1 - ロック管理システム、ロック管理方法およびロック管理用プログラム - Google Patents

Abstract

【課題】ロック取得や解放処理を高速に実施することのできるロック管理システム、ロック管理方法およびロック管理用プログラムを提供する。【解決手段】マルチプロセッサを有するロック管理システム１であって、１以上のロックモードによりスレッドのロック獲得を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ロック獲得処理３１０と、ロックを取得しているスレッド数を、マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するロック状態保持手段４１０とを備える。

Description

本発明に係るいくつかの態様は、マルチプロセッサ・システムにおけるロック管理システム、ロック管理方法およびロック管理用プログラムに関する。

計算機システムでは、プロセッサなどの計算機資源を効率的に使用するため、複数のプロセスやスレッドを並列に動作させることが一般的である。尚、厳密にはプロセスとスレッドは同一ではないが、プログラムを実行する単位を意味する点では同種の概念であることから、以下の説明では、プログラムを実行する単位を、全てスレッドと呼ぶ。

複数のプロセッサを有することにより複数のスレッドを同時かつ並列に実行することが可能に構成された情報システムでは、メモリ上に存在するデータに対して、複数のスレッドが並行にアクセスすることがある。各々のスレッドがアクセスするデータが独立している場合には、複数のスレッドがメモリに並行にアクセスしても問題となることは無い。しかしながら、関連するデータ、若しくは同一のデータに対して、複数のスレッドが互いを意識することなくアクセスすると、単一のスレッドがデータにアクセスした場合と異なる結果となる場合がある。

例として、２つのスレッドが同一の変数に１を加える処理、すなわち、両スレッドとも、変数を読み込んで１を加えた上でその結果を書き戻す、という処理を考える。第１のスレッドが変数に１を加える処理を完了した後で第２のスレッドが変数に１を加える処理を行う、という順で２つのスレッドが実行された場合には、変数の値は２増加する。各スレッドの処理内容を考えると、これは正しい結果である。一方、２つのスレッドが平行に実行される場合には、例えば、第１のスレッドが変数を読み込んでから１加えた結果を書き戻すまでの間に、第２のスレッドがその変数を読み出す、という順に処理が実行されることも有りうる。この順で処理が進むと、両スレッドとも、互いに別スレッドによる変数の更新を感知することなく、当初の値に１を加えた値を変数に書き戻すこととなるため、２つのスレッドが変数に１加える処理を行ったにも関わらず、変数の値は１増加するだけである。つまり、この場合には正しい結果は得られない。

このように、あるスレッドの処理の途中に他のスレッドの処理が行われると問題が発生する処理期間（上記の例では、スレッドがデータを読み込んでから、処理結果の値を書き戻すまでの期間）をクリティカルセクションと呼ぶ。正しい処理結果を得るためには、あるスレッドがクリティカルセクションの処理を実行している間に、他のスレッドの処理が割り込まないようにする制御を明示的に行う必要がある。

クリティカルセクションには、１スレッドのみが実行可能という最も単純な形態の他、実行可能なスレッド数に上限があるものや、排他ロック（書込ロック）と共有ロック（読出ロック）という２種類のロック形態があるものがある。実行可能なスレッド数に上限があるクリティカルセクションは、１スレッドのみが実行可能なクリティカルセクションを、実行可能なスレッド数の上限値という観点で汎用化したものと捉えることができる。共有ロックと排他ロックとがあるクリティカルセクションでは、排他ロックを取得してクリティカルセクション処理を実行できるスレッド数が１に制限される一方、共有ロックについては、同時実行可能なスレッドの数に上限はなく、排他ロックを取得して処理しているスレッドが無い限り、共有ロックを取得してクリティカルセクション処理を実行できる。

また、共有ロックと排他ロックとがあるクリティカルセクションの拡張として、複数のロックモードが用意されると共に、各モードの間で共存可能なスレッドの数が規定されているロック形態もある。非特許文献１は、このような複雑なロックの一例を開示している。非特許文献１記載の方式では、ロックモードとして、「ＡＣＣＥＳＳ ＳＨＡＲＥ」、「ＲＯＷ ＳＨＡＲＥ」、「ＲＯＷ ＥＸＣＬＵＳＩＶＥ」、「ＳＨＡＲＥ ＵＰＤＡＴＥ ＥＸＣＬＵＳＩＶＥ」、「ＳＨＡＲＥ」、「ＳＨＡＲＥ ＲＯＷ ＥＸＣＬＵＳＩＶＥ」、「ＥＸＣＬＵＳＩＶＥ」、「ＡＣＣＥＳＳ ＥＸＣＬＵＳＩＶＥ」の８つが規定されている。それぞれのロックモードに関し、同時に実行可能な（競合しない）ロックモード、及び同時には実行できない（競合する）ロックモードの関係がＴａｂｌｅ １３−２で規定されている。このような複数のモードを持つロック手法は、競合関係表を規定することで、種々の形態のロックを統一的に扱うことができる。

複数のプロセッサを有するマルチプロセッサ・システムにおいて、クリティカルセクションを実現する一般的な方法は、クリティカルセクションを実行中のプロセスが存在するか否かを示すフラグ（以降、ロックワード）を使用する方法である。最も単純なロックの場合、クリティカルセクションに入ろうとするスレッドは、まずロックワードを確認し、ロックワードが未使用を示す値（以降、「ｕｎｌｏｃｋ」という。）であれば、ロックワードを使用を示す値（以降、「ｌｏｃｋｅｄ」という。）に変更してクリティカルセクションの処理を実行する。一方、確認したロックモードがｌｏｃｋｅｄであれば、そのロックワードがｕｎｌｏｃｋｅｄになるまで待った後、それをｌｏｃｋｅｄに変更してクリティカルセクションの処理を実行する。また、そのスレッドがクリティカルセクションの実行を終了するとロックワードをｕｎｌｏｃｋｅｄに戻す処理を行う。このような制御により、他プロセッサが実行するスレッド処理を自プロセッサが実行するスレッド処理と同時にクリティカルセクションを実行する（処理が競合する）問題が発生しないようにできる。

排他ロックと共有ロックという２種類のロック形態があるロック手法の場合、ロックの状態は、（１）排他ロックを取得してクリティカルセクションを実行しているスレッドが存在するか否かを示す１ｂｉｔと、（２）共有ロックを取得してクリティカルセクションを実行しているスレッドの数を示す複数ｂｉｔ（最大スレッド数を表現可能なｂｉｔ数）とで表すことができる。この２種類の情報を、プロセッサが持つ不可分（ａｔｏｍｉｃ）なアクセス命令で扱うことのできる１ワードに収めることができる場合は、この命令を用いてこのロック手法を実現することができる。

不可分（ａｔｏｍｉｃ）なアクセス命令の一例としては、インテルのｘ８６プロセッサに用意されているｃｍｐｘｃｈｇ命令が挙げられる（非特許文献２参照。）。ｃｍｐｘｃｈｇ命令は、命令で予約されたレジスタ（ｅａｘレジスタ）とレジスタ・オペランドとメモリ・オペランドとの３オペランドを使用する命令である。これにより、ｃｍｐｘｃｈｇ命令は、（１）メモリ・オペランドの値をプロセッサに読み込む、（２−１）その値がｅａｘレジスタの値と一致する場合はメモリにレジスタ・オペランドの値を書き込む、（２−２）その値がｅａｘレジスタの値と一致しない場合はその値をｅａｘレジスタに書き込む、という一連の操作を不可分に行う。尚、ここでの不可分とは、（１）のメモリ読込操作と、（２−１）のメモリ書込操作との間に他のプロセッサがメモリをアクセスしないことがハードウェア動作によって保証されていることを意味する。

また、ｃｍｐｘｃｈｇ命令が（２−１）及び（２−２）のどちらを実行したのかは、ＣＡＳ命令実行後のｅａｘレジスタの値が実行前の値から変化しているかどうかを調べることにより判定することができる。なお、このｃｍｐｘｃｈｇ命令が行う操作を、以下ではＣＡＳ（Ｃｏｍｐａｒｅ Ａｎｄ Ｓｗａｐ）という。なお、プロセッサが持つ不可分（ａｔｏｍｉｃ）な命令としては、ＣＡＳ操作の他、メモリ中の１ワードを読みだして四則演算や論理演算を行った後、その結果を同じメモリ位置に書き込む命令もある。この不可分な演算命令では、最初のメモリ読み出し操作と演算結果をメモリに書き込む操作との間に、他のプロセッサからメモリアクセスが行われないことが保証される。

ＣＡＳ操作を用いて排他ロックと共有ロックという２種類のロック形態があるロック手法を実現する方法は、以下の通りである。ロックを取得しようとするスレッドは、まず、ロックワードを読込み、取得しようとしているモードのロックと競合するロックが取得されていないかどうかを調べる。具体的には、（１）スレッドが取得しようとしているモードが排他ロックの場合は、排他ロックと共有ロックの両方とも既に取得しているスレッドが存在しないこと、（２）スレッドが取得しようとしているモードが共有ロックの場合は、排他ロックを取得しているスレッドが存在しないこと、を確認する。その結果、取得しようとするモードのロックと競合するロックが取得されていない場合には、取得しようとしているモードのロックを取得した状態のロックワードを新しい値、そして、前の操作で読み出したロックワードの値を旧値とするＣＡＳ操作をロックワードに対して行えば良い。

ここで、新値の具体的な値は、（１）スレッドが取得しようとしているモードが排他ロックの場合は、ロックワードの内、排他ロックを取得してクリティカルセクションを実行しているスレッドが存在するか否かを示す１ｂｉｔをセットした値、（２）スレッドが取得しようとしているモードが共有ロックの場合は、ロックワードの内、共有ロックを取得してクリティカルセクションを実行しているスレッドの値を示す複数ｂｉｔで表される数値に１を加えた値、である。そして、上記のＣＡＳ操作が成功すると、そのスレッドはロック取得に成功し、クリティカルセクションの実行を開始することとなる。このＣＡＳ操作で失敗した場合には、ＣＡＳ操作で読み出したロックワードの値を旧値として最初からやり直すこととなる。また、読みだしたロックワードを調べた結果、取得しようとするモードのロックと競合するロックが取得されている場合には、当該競合するロックが解放されるまで待つこととなる。

以上説明したように、規定されている全てのロックモードについて、そのモードでロックを取得しているスレッド数をプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できる場合は、そのワードを読み出した後にＣＡＳアクセスを行う、という単純な形でロック取得操作を実現することができる。

一方、複数のロックモードが用意されており、各モードの間で共存可能なスレッド数が規定されている形態のロック方法では、規定されている全てのロックモードについて、そのモードでロックを取得しているスレッド数を、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できないこととなるため、上記のような、単純な形でロック取得操作を実現することはできない。

このような場合に、規定されている全てのロックモードについて、それらのモードのロックを取得しているスレッド数を保持する配列と、その配列へのアクセスを排他制御するための機構（以下、ｍｕｔｅｘという。）を用意することがある。この手法では、ロックを取得するスレッドは、まずｍｕｔｅｘを取得した後、前記の配列にアクセスしてロックの取得可否を判断する。その結果、ロックが取得可能な場合には、ロックモードに対応する配列要素の１加えた後、ｍｕｔｅｘを解放する、という形でロック取得操作を実現することとなる。

ＰｏｓｔｑｒｅＳＱＬ ９．０．７ Ｄｏｃｕｍｅｎｔａｔｉｏｎ Ｃｈａｐｔｅｒ １３ Ｃｏｎｃｕｒｒｅｎｃｙ Ｃｏｎｔｒｏｌ［ｏｎｌｉｎｅ］、［平成１２年５月１１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｐｏｓｔｇｒｅｓｑｌ．ｏｒｇ／ｄｏｃｓ／９．０／ｓｔａｔｉｃ／ｅｘｐｌｉｃｉｔ−ｌｏｃｋｉｎｇ．ｈｔｍｌ＞ Ｉｎｔｅｌ（Ｒ） ６４ ａｎｄ ＩＡ−３２ Ａｒｃｈｉｔｅｃｔｕｒｅｓ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｅｒ’ｓ Ｍａｎｕａｌ Ｖｏｌｕｍｅ ２Ａ［ｏｎｌｉｎｅ］、［平成１２年５月１１日検索］、インターネット＜ＵＲＬ： ｈｔｔｐ：／／ｗｗｗ．ｉｎｔｅｌ．ｃｏｍ／Ａｓｓｅｔｓ／ＰＤＦ／ｍａｎｕａｌ／２５３６６６．ｐｄｆ＞

しかしながら、このようなロック手法では、ｍｕｔｅｘの競合が問題となる可能性がある。この問題は、特にロック要求の大半が競合しないロックモードであり、且つ、その要求頻度が高い場合に顕著となる。ロックでは競合が発生しないにもかかわらず、ロック要求の頻度が高いためにｍｕｔｅｘで競合が発生するので、このｍｕｔｅｘの取得がボトルネックとなることがあるためである。

つまり、ロックで規定されている全てのロックモードについて、そのモードでロックを取得しているスレッド数をプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できない場合において、特に、ロック要求の大半が競合しないロックモードであり、その頻度が高い状況では、ロック状態を保持する変数群を保護するための排他制御における競合がボトルネックとなる可能性がある。

本発明のいくつかの態様は前述の課題に鑑みてなされたものであり、規定されている全てのロックモードについて、そのモードでロックを取得しているスレッド数をプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できない場合であっても、ロック取得や解放処理を高速に実施することのできるロック管理システム、ロック管理方法およびロック管理用プログラムを提供することを目的の１つとする。

本発明のロック管理システムは、マルチプロセッサを有するロック管理システムであって、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ロック取得手段と、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理する管理手段とを備える。

本発明のロック管理方法は、マルチプロセッサを有するロック管理システムのロック管理方法であって、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップとを備える。

本発明のロック管理用プログラムは、マルチプロセッサを有するロック管理システムに、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップとを実行させる。

尚、本発明において、「部」や「手段」、「装置」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「手段」、「装置」の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、規定されている全てのロックモードについて、そのモードでロックを取得しているスレッド数をプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できない場合であっても、ロック取得や解放処理を高速に実施することのできるロック管理システム、ロック管理方法およびロック管理用プログラムを提供することができる。

第１の実施形態に係るロック管理システムの概略構成を示す機能ブロック図である。 第１の実施形態で使用するビットマスク型データおよびロック状態ビットマスクの構造を示す図である。 第１の実施形態で使用するカウンタ配列、待ち行列、待ち行列エントリ、およびＭｕｔｅｘの構造を示す図である。 第１の実施形態に係るスレッド固有データとスレッドとの関係を示す図である。 図１に示したロック管理システムにおけるＣＡＳ操作の処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック獲得処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 図１に示したロック管理システムにおけるロック解放処理の流れを示す図である。 ロックの競合関係を扱うためのビットマスク型データの配列構造を示す図である。 第２の実施形態で使用するロック状態ビットマスクの構造を示す図である。 第２の実施形態に係るロック管理システムにおけるロック獲得処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック獲得処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック獲得処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック獲得処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック獲得処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。 第２の実施形態に係るロック管理システムにおけるロック解放処理の流れを示す図である。

以下に本発明の実施形態を説明する。以下の説明及び参照する図面の記載において、同一又は類似の構成には、それぞれ同一又は類似の符号が付されている。

（１ 第１の実施形態）
以下、ロック手法におけるロック取得要求は、０乃至ｎのいずれかのロックモードで行われるものとして、本実施形態に係るロック管理システム、ロック管理方法およびロック管理用プログラムについて説明する。

（１．１ 機能構成）
図１に、本実施形態に係るスレッドを実行するロック管理システム１の機能構成を示す。ロック管理システム１は、スレッドを実行する複数のプロセッサ１００Ａ乃至１００Ｄ（以下、プロセッサ１００Ａ乃至１００Ｄを総称してプロセッサ１００と呼ぶ）と、メモリ２００とを含む。

メモリ２００は、スレッドが実行するプログラム３００と、スレッドとがプログラムを実行する際に使用するデータ４００とが格納される。プログラム３００は、ロック獲得処理３１０、ロック解放処理３２０、スレッド休眠処理３３０、スレッド起床処理３４０を含む。データ４００は、ロック状態ビットマスク４１１、カウンタ配列４１３、待ち行列４１５、ｍｕｔｅｘ４１７を含むロック状態保持手段４１０と、ロックモードの競合関係を示す競合関係表４２０とを含む。

ロック状態ビットマスク４１１について、図２を参照しながら説明する。ロック状態ビットマスク４１１は、ｇｒａｎｔＭａｓｋとｗａｉｔＭａｓｋという２つのビットマスク型データから構成されている。ここで、ビットマスク型データは、ロックモード０からｎに対応するビット０からｎの集まりである。

ｇｒａｎｔＭａｓｋは各ロックモードを取得しているスレッドの有無、ｗａｉｔＭａｓｋは各ロックモードが取得可能になるのを待っているスレッドの有無を、ビット０乃至ｎで表現している。本実施形態では、ｇｒａｎｔＭａｓｋにて各ロックモードに割り当てられるビット数は１ビットなので、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な値の最大値は１である。以下では、ビットマスク型のデータにおいて、ビットｍのみをセットした定数をｂｉｔ（ｍ）、また、ｂｉｔ（ｍ）の前ビットを反転させた定数を〜ｂｉｔ（ｍ）と表記する。

図３を参照すると、カウンタ配列４１３は、ロックモード０からｎに対応して、ＯｗｎｅｒとＷａｉｔｅｒの値を保持する変数の配列である。待ち行列４１５は、スレッドＩＤとロックモードとを記録する待ち行列エントリを要素としている。また、Ｍｕｔｅｘ４１７は、１スレッドのみが実行可能という最も単純な排他制御を実現するためのデータである。

これらのデータの内、ロック状態ビットマスク４１１、カウンタ配列４１３の一要素（ＯｗｎｅｒやＷａｉｔｅｒ変数）はプロセッサ１００が備える不可分アクセスで扱うことができるものとする。

また、競合関係表４２０は、要素の数がロックモードの数であるビットマスク型データの読み出し専用配列である。競合関係表４２０には、予めロックの競合関係が設定されているものとする。以下、競合関係表をｃｏｎｆｌｉｃｔ、ロックモードｎに対応するビットマスク型データをｃｏｎｆｌｉｃｔ［ｎ］と表記する。

図４は、プロセッサ１００で実行されるスレッド１１０が参照するメモリ２００上の固有データを示す。図４を参照すると、メモリ２００中には、各スレッド１１０（スレッド１１０ａ乃至１１０ｔ／スレッド１１０Ａ乃至１１０Ｄを総称してスレッド１１０という。）に対応するスレッド固有領域（スレッド固有データ４３０ａ乃至４３０ｔ）がある。また、各スレッド固有領域（スレッド固有データ４３０ａ乃至４３０ｔ）は、ビットマスク型のデータであるｈｏｌｄＭａｓｋを含んでいる。

（１．２ 処理の流れ）
次に、図５乃至図２１を参照しながら、本実施形態に係るロック管理システム１の処理の流れを説明する。

（１．２．１ ＣＡＳ操作）
まず、図５を参照しながら、本実施形態におけるＣＡＳ操作の処理の流れを説明する。ＣＡＳ操作のパラメータは、ＣＡＳ操作対象データが存在する対象アドレス（Ａ）、旧値（Ｏ）、新値（Ｎ）である。その動作は、まず、対象アドレスで示されるメモリ位置から現在の値（ｃとする）を読出し（Ｓ１−１）、その値を旧値（Ｏ）と比較する（Ｓ１−２）。その結果、両者が等しい場合には、対象アドレスで示されるメモリ位置に新値（Ｎ）を格納した後（Ｓ１−３）、ＣＡＳ操作結果を成功として（Ｓ１−４）ＣＡＳ操作を終了する。一方、Ｓ１−２での比較の結果、両者が等しくない場合には、変数Ｏにｃを格納した後（Ｓ１−５）、ＣＡＳ操作結果を失敗として（Ｓ１−６）ＣＡＳ操作を終了する。

スレッド休眠処理は、その処理を読み出したスレッドを休眠させる処理である。スレッド起床処理は、パラメータとして与えられたスレッドＩＤで示されるスレッドを起床する処理である。簡単のため、スレッド起床処理が先に呼び出された後、起床対象スレッドがスレッド休眠処理を実行した場合、そのスレッドは休眠することなく実行を継続するものとする。このような休眠処理および起床処理は、従来技術であるセマフォを各スレッドに持たせることにより実現可能である。

（１．２．２ ロック取得処理）
次に、図６から図１４のフローチャートを参照しながら、本実施形態におけるロック取得処理（ロック獲得処理３１０）について説明する。ここで、このロック取得処理でのみ使用する変数は、旧ｇｒａｎｔＭａｓｋと旧ｗａｉｔＭａｓｋとからなる旧ロック状態ビットマスク値と、新ｇｒａｎｔＭａｓｋと新ｗａｉｔＭａｓｋとからなる新ロック状態ビットマスク値と、ＣＡＳ操作が必要かどうかを示すフラグであるｎｅｅｄＣＡＳと、ロック取得結果を示すｌｏｃｋＲｅｓｕｔとである。

あるスレッドがロックモードｍのロックを取得する処理を起動すると、ｇｒａｎｔＭａｓｋとｗａｉｔＭａｓｋとからなる現在のロック状態ビットマスク値を読出し、旧ロック状態ビットマスク変数に設定する（ＳＢ１）。次に、ロック状態ビットマスクを新ロック状態ビットマスク変数に設定する（ＳＢ２）。

その後、ｃｏｎｆｌｉｃｔ［ｍ］と旧ｗａｉｔＭａｓｋとの論理積が０でなく、かつ、自スレッドのｈｏｌｄＭａｓｋが０であるかどうかを調べる（ＳＢ３）。最初の条件が成立する、すなわち、論理積が０でない値となるのは、スレッドが取得しようとしているロックモードと競合するロックが待ち状態となっている場合である。この条件が成立すると、スレッドはロックを取得できないため、ロックが取得できない場合の処理（ラベルｂＦ）へ進む。また、ＳＢ３の条件が成立しない場合は、ロックを取得する処理（ラベルｂ２）へ進む。

ロックを取得する処理（ラベルｂ２。図８）では、まず、ｃｏｎｆｌｉｃｔ［ｍ］と旧ｇｒａｎｔＭａｓｋとの論理積が０かどうかを調べる（ＳＢ４）。この論理積が０でない値となるのは、スレッドが取得しようとしているロックモードと競合するロックが既に取得されている場合である。従って、この論理積が０でないときは、ロックが取得できない場合の処理（ラベルｂＦ）へと進む。一方、この論理積が０の場合には、ロック結果を格納する局所変数（ｌｏｃｋＲｅｓｕｌｔ）にＯＫを示す値を入れ（ＳＢ５）、旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）が設定されているかどうかを調べる（ＳＢ６）。旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）が設定されていない状態は、そのロックモードのロックを取得しているスレッドが存在しない状態なので、ロック状態ビットマスクの操作が必要かどうかの情報を格納する局所変数ｎｅｅｄＣＡＳにＴＲＵＥを示す値を入れると共に（ＳＢ７）、旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）を設定した値をＣＡＳ操作で使用する新ｇｒａｎｔＭａｓｋとして（ＳＢ８）、ビットマスクを操作する処理（ラベルｂＣ）へと進む。

一方、ＳＢ４で旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）が設定されている状態は、他のスレッドがそのロックモードのロックを取得している状態であるので、ｎｅｅｄＣＡＳにＦＡＬＳＥを示す値を入れた後（ＳＢ９）、ビットマスクを操作する処理（ラベルｂＣ）へと進む。

ロックが取得できない場合の処理（ラベルｂＦ。図９）では、まず、ｌｏｃｋＲｅｓｕｌｔにＮＧを示す値を入れ（ＳＢ１０）、次に旧ｗａｉｔＭａｓｋのｂｉｔ（ｍ）が設定されているかどうかを調べる（ＳＢ１１）。旧ｗａｉｔＭａｓｋのｂｉｔ（ｍ）が設定されていない状態は、そのロックモードのロックを取得しようとしている休眠スレッドが存在しない場合であるので、ｎｅｅｄＣＡＳにＴＲＵＥを示す値を入れると共に（ＳＢ１２）、旧ｗａｉｔＭａｓｋのｂｉｔ（ｍ）を設定した値をＣＡＳ操作で使用する新ｗａｉｔＭａｓｋとした上で（ＳＢ１３）、ビットマスクを操作する処理（ラベルｂＣ）へと進む。

一方、ＳＢ１１で旧ｗａｉｔＭａｓｋのｂｉｔ（ｍ）が設定されている状態は、他のスレッドがそのロックモードのロックを取得しようとして休眠している状態なので、ｎｅｅｄＣＡＳにＦＡＬＳＥを示す値を入れた上で（ＳＢ１４）、ビットマスクを操作する処理（ラベルｂＣ）へと進む。

ビットマスクを操作する処理（ラベルｂＣ。図１０）では、まず、ｎｅｅｄＣＡＳの値を調べる（ＳＢ１５）。この結果、ｎｅｅｄＣＡＳがＦＡＬＳＥの場合には（ＳＢ１５のＮｏ）カウンタ配列を操作する処理（ラベルｂＳ）へと進む。一方、ｎｅｅｄＣＡＳの値がＴＲＵＥである場合には（ＳＢ１５のＹｅｓ）、対象アドレスをロック状態ビットマスクのアドレス、旧値を旧ビットマスク値、すなわち、旧ｇｒａｎｔＭａｓｋと旧ｗａｉｔＭａｓｋの値、新値を新ビットマスク値、すなわち、新ｇｒａｎｔＭａｓｋと新ｗａｉｔＭａｓｋの値とするＣＡＳ操作を実施する（ＳＢ１６）。なお、新ｇｒａｎｔＭａｓｋや新ｗａｉｔＭａｓｋが、それまでに実行された処理ステップで設定されていない場合には、ステップＢ２で設定した旧Ｍａｓｋ値が残っていることになる。このＣＡＳ操作が成功したかどうかを判定し（ＳＢ１７）、ＣＡＳ操作が失敗した場合には（ＳＢ１７のＮｏ）、ＳＢ２へ戻って一連の処理をやり直す（ラベルｂＡ）。また、ＣＡＳ操作が成功した場合には（ＳＢ１７のＹｅｓ）、カウンタ配列を操作する処理（ラベルｃＳ）へと進む。

カウンタ配列を操作する処理（ラベルｃＳ、図１１）では、まず、ｌｏｃｋＲｅｓｕｌｔの値を調べる（ＳＣ１）。この結果、ｌｏｃｋＲｅｓｕｌｔがＯＫでない場合（ＮＧの場合。ＳＣ１のＮｏ）には、カウンタ配列のうち、Ｗａｉｔｅｒを操作する処理（ラベルｃＷ）へと進む。一方、ｌｏｃｋＲｅｓｕｌｔがＯＫの場合は（ＳＣ１のＹｅｓ）、ｎｅｅｄＣＡＳの値を調べる（ＳＣ２）。この結果、ｎｅｅｄＣＡＳがＴＲＵＥの場合には（ＳＣ２のＹｅｓ）、カウンタ配列の内Ｏｗｎｅｒ［ｍ］に不可分加算により１を加え、ラベルｃＥへと進む。一方、ｎｅｅｄＣＡＳがＦＡＬＳＥの場合にはＯｗｎｅｒ［ｍ］の値を読出し、ＣＡＳ操作のための局所変数である旧ｃｏｕｎｔｅｒに設定した後（ＳＣ５）、旧ｃｏｕｎｔｅｒ値が０かどうかを調べる（ＳＣ６）。旧ｃｏｕｎｔｅｒ値が０の場合は（ＳＣ６のＹｅｓ）、ＳＢ２へ戻って一連の処理をやり直す（ラベルｂＡ）。一方、旧ｃｏｕｎｔｅｒ値が０でない場合には（ＳＣ６のＮｏ）、対象アドレスをＯｗｎｅｒ［ｍ］のアドレス、旧値を旧ｃｏｕｎｔｅｒ値、新値を旧ｃｏｕｎｔｅｒ値＋１とするＣＡＳ操作を実施する（ＳＣ７）。次に、ＣＡＳ操作が成功したかどうかを調べる（ＳＣ８）。ＣＡＳ操作が失敗した場合には（ＳＣ８のＮｏ）、ＳＣ６へ戻る。ＣＡＳ操作に成功した場合には（ＳＣ８のＹｅｓ）、ラベルｃＥへと進む。

カウンタ配列のうち、Ｗａｉｔｅｒを操作する処理では、まず、ｍｕｔｅｘを取得し（ＳＣ９）、ｃｏｎｆｌｉｃｔ［ｍ］とｇｒａｎｔＭａｓｋとの論理積が０かどうかを調べる（ＳＣ１０）。この論理積が０の場合には（ＳＣ１０のＹｅｓ）、スレッドが取得しようとしているロックモードと競合するロックが取得されておらず、スレッドが要求しているロックモードでのロックを取得できる場合であるので、ｍｕｔｅｘを解放し（ＳＣ１１）、ＳＢ２へ戻って一連の処理をやり直す。尚、この処理フローが生じるのは、ＳＢ４でｃｏｎｆｌｉｃｔ［ｍ］とｇｒａｎｔＭａｓｋの論理積を調べてからＳＣ１０で同じ論理積を調べるまでの間に、競合するロックを取得している他のスレッドがそのロックを開放した場合である。

一方、ＳＣ１０で調べた論理積が０でない場合は（ＳＣ１０のＮｏ、ラベルｃＣ）、ｎｅｅｄＣＡＳの値を調べる（ＳＣ１２）。この結果、ｎｅｅｄＣＡＳがＴＲＵＥの場合には（ＳＣ１２のＹｅｓ）、カウンタ配列のうち、Ｗａｉｔｅｒ［ｍ］に不可分加算により１を加えた後（ＳＣ１３）、自スレッドを待ち行列につなぐ処理へと進む（ラベルｃＰ）。一方、ＳＣ１２でｎｅｅｄＣＡＳがＦＡＬＳＥの場合には（ＳＣ１２のＮｏ）、Ｗａｉｔｅｒ［ｍ］の値を読みだして、これをＣＡＳ操作のための局所変数である旧ｃｏｕｎｔｅｒに設定した上で（ＳＣ１４）、旧ｃｏｕｎｔｅｒ値が０かどうかを調べる（ＳＣ１５）。旧ｃｏｕｎｔｅｒ値が０の場合には（ＳＣ１５のＹｅｓ）、ｍｕｔｅｘを解放し（ＳＣ１８）、ＳＢ２へ戻って一連の処理をやり直す（ラベルｂＡ）。一方、旧ｃｏｕｎｔｅｒ値が０でない場合には（ＳＣ１５のＮｏ）、対象アドレスをＷａｉｔｅｒ［ｍ］のアドレス、旧値を旧ｃｏｕｎｔｅｒ値、新値を旧ｃｏｕｎｔｅｒ値＊１とするＣＡＳ操作を実施する（ＳＣ１６）。この結果、ＣＡＳ操作が失敗した場合には（ＳＣ１７のＮｏ）、ＳＣ１５から処理をやり直す。ＣＡＳ操作が成功した場合には（ＳＣ１７のＹｅｓ）、自スレッドを待ち行列に繋ぐ処理へと進む（ラベルｃＰ）。

自スレッドを待ち行列につなぐ処理（ラベルｃＰ、図１４）では、まず、待ち行列エントリを作成し、自スレッドに付与されたＩＤと要求しているロックモード（ｍ）とを設定する（ＳＣ１８）。次に、作成した待ち行列エントリを待ち行列につなぎ（ＳＣ１９）、ｍｕｔｅｘを解放した後（ＳＣ２０）、スレッド休眠処理により休眠する（ＳＣ２１）。休眠したスレッドが起床すると、自スレッドのｈｏｌｄＭａｓｋのｂｉｔ（ｍ）をセットし（ＳＣ２２）、ロックモードｍのロック取得操作を終了する。

（１．２．３ ＬｏｃｋＭｏｄｅ解放処理）
続いて、図１５乃至図２１を参照しながら、本実施形態におけるロック解放処理を説明する。この処理でのみ使用する局所変数は、ロック解放を休眠して待っているスレッドを起床する際に使用するもので、旧ｇｒａｎｔＭａｓｋと旧ｗａｉｔＭａｓｋとからなる旧ロック状態ビットマスクと、新ｇｒａｎｔＭａｓｋと新ｗａｉｔＭａｓｋとからなる新ロック状態ビットマスク値と、ＣＡＳ操作が必要かどうかを示すフラグであるｎｅｅｄＣＡＳと、待ち行列において操作対象である待ち行列エントリを示すポインタと、操作対象の待ち行列エントリが保持しているロックモードを保持する変数ｗと、起床対象スレッドを保持する起床対象リスト、および、起床対象リストに繋がれた全待ち行列エントリのロックモードについての論理和を保持するためのビットマスク型の変数（ＰｒｅｃｅｄＭａｓｋ）である。起床対象リストは、待ち行列と同様の構造を持つデータであり、複数の待ち行列エントリを保持するようになっている。

ロックモードｍのロックを取得しているスレッドが、そのロックを解放する処理を起動すると、Ｏｗｎｅｒ［ｍ］に不可分加算により１を減算、すなわち、−１を加えた後（ＳＲ１）、不可分加算の結果を調べる（ＳＲ２）。その結果が０でないのは（ＳＲ２のＮｏ）、他のスレッドがそのロックモードでロックを取得している場合であるので、自スレッドのｈｏｌｄＭａｓｋのｂｉｔ（ｍ）をリセットして（ＳＲ３）、ロックを解放する操作を終了する。一方、不可分加算の結果が０の場合は（ＳＲ２のＹｅｓ）、ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）を不可分論理積によってリセットし（ＳＲ４）、ｃｏｎｆｌｉｃｔ［ｍ］とｗａｉｔＭａｓｋとの論理積を調べる（ＳＲ５）。この結果が０となるのは（ＳＲ５のＹｅｓ）、ロックモードｍの解放を待っているスレッドが存在しない場合であるので、ＳＲ３に進んで自スレッドのｈｏｌｄＭａｓｋのｂｉｔ（ｍ）をリセットし、ロックを解放する操作を終了する。

一方、ＳＲ５において、ｃｏｎｆｌｉｃｔ［ｍ］とｗａｉｔＭａｓｋとの論理積が０でない場合には、ロックモードｍの解放を待っているスレッドが存在していることから、待ち状態のスレッドを起床する処理を行う（ラベルｒＷ）。

待ち状態のスレッドを起床する処理（ラベルｒＷ。図１６）では、まず、ｍｕｔｅｘを取得し（ＳＲ６）、待ち行列からの読出し位置、ｐｒｅｃｅｄＭａｓｋ、起床対象リストを、それぞれ待ち行列の先頭エントリ、０、空に初期化する（ＳＲ７）次に、待ち行列につながれている全エントリについて待ち行列エントリに対応するスレッドが要求しているロックモードｗのロックが取得可能かどうかを調べ、取得可能な場合にはロック状態を変更した後、そのスレッドを起床する。具体的には、まず、読出し位置にエントリが存在しているかどうかを調べ（ＳＲ８）、その結果、読出し位置にエントリが存在していないのは（ＳＲ８のＮｏ）待ち行列につながれた全エントリに対して処理を終えたことを意味しているので、ｍｕｔｅｘを解放し（ＳＲ９）、起床対象リストにつながれた全待ち行列のエントリを起床した後、それらの待ち行列エントリを削除し（ＳＲ１０）、更に、自スレッドのｈｏｌｄＭａｓｋのｂｉｔ（ｍ）をリセットして（ラベルｒＥ、ＳＲ３）。ロックを解放する処理を終了する。

一方、ＳＲ８において、読出し位置にエントリが存在している場合には（ＳＲ８のＹｅｓ）、読出し位置にある待ち行列エントリについてロック取得操作を行ない（ＳＲ１１）、読出し位置を待ち行列におけるそのエントリの次の位置に移動し（ＳＲ１２）、ＳＲ８に戻ってループ処理を繰り返す。

待ち行列エントリについてのロック取得操作（図１７）では、まず、その待ち行列エントリに記録されているロックモードをｗとし（ＳＡ１）、ｇｒａｎｔＭａｓｋとｗａｉｔＭａｓｋとからなる現在のロック状態ビットマスク値を読出し、旧ロック状態ビットマスク変数に設定する（ＳＡ２）。次に、旧ロック状態ビットマスクを新ロック状態ビットマスク変数に設定する（ＳＡ３）。

そして、ｃｏｎｆｌｉｃｔ［ｗ］とｐｒｅｃｅｄＭａｓｋとの論理積が０でなく、かつ、ｃｏｎｆｌｉｃｔ［ｗ］と旧ｇｒａｎｔＭａｓｋとの論理積が０であるかどうかを調べる（ＳＡ４）。この条件が成立しないのは（ＳＡ４のＮｏ）、ロックモードｗのロックが取得できない場合であるので、その待ち行列エントリについてのロック取得操作を終了する（ラベルｒＮ）。一方、ＳＡ４の条件が成立すると（ＳＡ４のＹｅｓ）、旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｗ）が設定されているかどうかを調べる（ＳＡ６）。旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｗ）が設定されていない場合は（ＳＡ６のＹＥＳ）、ｎｅｅｄＣＡＳにＴＲＵＥを示す値を入れ（ＳＡ７）、旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｗ）を設定した値をＣＡＳ操作で使用する新ｇｒａｎｔＭａｓｋとし（ＳＡ８）、ビットマスクを操作する処理（ラベルｒＢ）へ進む。一方、旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｗ）が設定されている場合には（ＳＡ６のＮｏ）、ｎｅｅｄＣＡＳにＦＡＬＳＥを示す値を入れ（ＳＡ９）、ビットマスクを操作する処理（ラベルｒＢ）へ進む。

ビットマスクを操作する処理（ラベルｒＢ。図１９）では、まず、ｎｅｅｄＣＡＳの値を調べる（ＳＡ１０）。この結果、ｎｅｅｄＣＡＳがＦＡＬＳＥの場合は（ＳＡ１０のＮｏ）、カウンタ配列を操作する処理（ラベルｒＳ）へと進む。一方、ｎｅｅｄＣＡＳがＴＲＵＥの場合には（ＳＡ１０のＹｅｓ）、対象アドレスをロック状態ビットマスクのアドレス、旧値を旧ビットマスク値、すなわち、旧ｇｒａｎｔＭａｓｋと旧ｗａｉｔＭａｓｋの値、新値を新ビットマスク値、すなわち、新ｇｒａｎｔＭａｓｋと新ｗａｉｔＭａｓｋの値とするＣＡＳ操作を実施する（ＳＡ１１）。尚、新ｇｒａｎｔＭａｓｋや新ｗａｉｔＭａｓｋが、それまでに実行された処理ステップで設定されていない場合は、ＳＡ２で設定した旧Ｍａｓｋ値が残っていることになる。次に、このＣＡＳ操作が成功したかどうかを判定し（ＳＡ１２）、ＣＡＳ操作が失敗した場合は（ＳＡ１２のＮｏ）ＳＡ３に戻って一連の処理をやり直す（ラベルｒＡ）。一方、ＣＡＳ操作が成功した場合には（ＳＡ１２のＹｅｓ）、カウンタ配列を操作する処理（ラベルｒＳ）へと進む。

カウンタ配列を操作する処理（ラベルｒＳ。図２０）では、ｎｅｅｄＣＡＳの値を調べる（ＳＡ１３）。この結果、ｎｅｅｄＣＡＳがＴＲＵＥの場合は（ＳＡ１３のＹＥＳ）、カウンタ配列のうち、Ｏｗｎｅｒ［ｗ］に不可分加算により１を加えてからスレッド起床準備操作（ラベルｒＢ）へと進む。一方、ｎｅｅｄＣＡＳがＦＡＬＳＥの場合には（ＳＡ１３のＮｏ）、Ｏｗｎｅｒ［ｗ］の値を読出し、ＣＡＳ操作のための局所変数である旧ｃｏｕｎｔｅｒにこの値を設定した後（ＳＡ１５）、旧ｃｏｕｎｔｅｒ値が０かどうかを調べる（ＳＡ１６）。旧ｃｏｕｎｔｅｒ値が０の場合は、ＳＡ３に戻って一連の処理をやり直す（ラベルｒＡ）。一方、旧ｃｏｕｎｔｅｒ値が０でない場合には（ＳＡ１６のＮｏ）、対象アドレスをＯｗｎｅｒ［ｍ］のアドレス、旧値を旧ｃｏｕｎｔｅｒ値、新値を旧ｃｏｕｎｔｅｒ値＋１とするＣＡＳ操作を実施する（ＳＡ１７）。次に、ＣＡＳ操作が成功したかどうかを調べる（ＳＡ１８）。ＣＡＳ操作が失敗した場合には（ＳＡ１８のＮｏ）、ＳＡ１６から処理をやり直す。ＣＡＳ操作が成功した場合には（ＳＡ１８のＹｅｓ）、ＳＡ１９へと進む（ラベルｒＧ）。

スレッド起床準備操作（ラベルｒＧ。図２１）では、まず、操作対象待ち行列エントリを待ち行列から外し（ＳＡ１９）、それを起床対象リストへと繋ぐ（ＳＡ２０）。次に、Ｗａｉｔｅｒ［ｗ］に不可分加算により１を減算、すなわち−１を加えた後（ＳＡ２１）、不可分加算の結果を調べる（ＳＡ２２）。その結果が０の場合は（ＳＡ２２のＹｅｓ）ｗａｉｔＭａｓｋのｂｉｔ（ｗ）をセットし（ＳＡ２４）、待ち行列エントリについての処理を終了する。一方、ＳＡ２２で不可分加算の結果が０でない場合は（ＳＡ２２のＮｏ）ＳＡ２３をスキップして、ＳＡ２４へと進む。

（１．３ 本実施形態に係る効果）
以上説明した通り、本実施形態によれば、ロックで規定されている全てのロックモードについて、そのモードのロックを取得しているスレッド数を、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できない場合であっても、競合しないロックモードでのロック要求については、ロック状態を保持する変数群を保護するためのｍｕｔｅｘを使用することなくロック要求を処理できるロック方法を実現できる。

つまり、ロックで規定されている総てのロックモードについて、そのモードのロックを取得しているスレッド数をプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現できない場合において、特に、ロック要求の大半が競合しないロックモードであり、その頻度が高い状況であっても、ロック状態を保持する変数群をアクセスするための排他制御に起因するボトルネックを生じさせないでロック取得や解放処理を高速に実施することのできるロック方法を提供することができる。

その理由は、既に取得されているロックと競合しないロック取得を要求された場合は、ロック状態を保持する変数群に対し、ロック操作に矛盾を生じないように考案したアルゴリズムに沿ってプロセッサが備える不可分アクセス命令や不可分演算命令によりアクセスすることでロック取得要求を処理することができるからである。すなわち、ロック状態を保持する変数群をアクセスするための排他制御が不要にできるため、そのような排他制御に起因するボトルネックを生じさせないでロック取得操作を実施することができる。

（１．４ 付記事項）
尚、本実施形態では、簡単のため、全てのロックモードについて、そのモードのロックを取得しているスレッド数が取りうる値の範囲全部を表現する情報（Ｏｗｎｅｒ［ｍ］）を操作する方法を説明したが、これに限られるものではない。例えば、取得可能なスレッド数が１となっているモード（排他ロック）については、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な値の範囲を扱う情報のみを操作する従来技術で対応することで、Ｏｗｎｅｒ［ｍ］の操作を省略することも可能である。この場合には、複数のスレッドがロックを取得可能なモード（共有ロック）の管理を本実施形態で説明した方法で行う、すなわち、従来技術と本実施形態とを組合せた方法で行うこととなる。

更に、本実施形態では、不可分演算が使用可能な処理についてはＣＡＳ操作ではなく、不可分演算操作を使用している。この不可分演算操作はＣＡＳ操作を使って実現できることは明らかであるため、本実施形態において不可分演算操作により行った処理をＣＡＳ操作で代用するように変更しても良い。

（２ 第２の実施形態）
（２．１ 概要）
次に、図２３乃至図３４を参照しながら、第２の実施形態に係るロック管理システム１およびプログラム３００によるロック管理方法として、ロック・プロモーションの可能なロック方法について説明する。尚、以下の説明において、第１の実施形態と共通または同様のシステム構成や作用効果等に係る各種説明は省略している。

ロック・プロモーションとは、あるロックモードのロックを獲得しているスレッドが、別のロックモードのロックを獲得することである。１つの特徴は、既に獲得しているロックモードと、これから獲得しようとするロックモードとが競合関係にある場合でも、他のスレッドが、これから獲得しようとするロックモードと競合関係にあるロックモードを獲得していない場合には、ロックの取得が可能である点、すなわち、自スレッドが獲得しているモードのロックは競合判定の対象外となる点である。

図２３を参照すると、本実施形態におけるロック状態ビットマスク４１１は、ｍｕｌｔｉＭａｓｋとｇｒａｎｔＭａｓｋとｗａｉｔＭａｓｋとのビットマスク型データから構成されている。このロック状態ビットマスク４１１は、プロセッサ１００が持つ不可分アクセス命令で扱うことのできる１ワードに収まっているものとする。ｇｒａｎｔＭａｓｋとｗａｉｔＭａｓｋとの意味は第１の実施形態と同じであり、ｍｕｌｔｉＭａｓｋは各ロックモードを取得しているスレッドが２つ以上存在しているかどうかを示す。すなわち、あるロックモードｍに対して、そのロックモードでロックを取得しているスレッド数が２以上の場合は、ｍｕｌｔｉＭａｓｋとｇｒａｎｔＭａｓｋとの両方ともｂｉｔ（ｍ）はセットされており、そのロックモードでロックを取得しているスレッド数が１の場合はｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）はセットされている一方、ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）はセットされていない状態となる。つまり、本実施形態に係るロック方法は、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードにより、ロックを保持しているスレッド数を最大２まで表現できるようにしたものである。

（２．２ 処理の流れ）
図２４から図３４を参照して、本実施形態に係る処理の流れを説明する。ここで、処理の多くの部分は、第１の実施形態と同様であるため、以下では異なる部分を中心に説明する。

まず、ロック状態ビットマスクにｍｕｌｔｉＭａｓｋが加わったことにより、ＳＢ１、ＳＢ２、ＳＢ１６、ＳＡ２、ＳＡ３、ＳＡ１１はｇｒａｎｔＭａｓｋ、ｗａｉｔＭａｓｋと同様の操作を、ｍｕｌｔｉＭａｓｋに対しても行うように変更する（それぞれ、ＳＢ１’、ＳＢ２’、ＳＢ１６’、ＳＡ２’、ＳＡ３’、ＳＡ１１’として図に示す）。

また、ロックが取得可能かどうかの判定において、既に自スレッドが獲得しているロックモードを考慮から外す条件を加える。具体的には、ＳＢ４において、ｃｏｎｆｌｉｃｔ［ｍ］と論理積をとる値を、ｇｒａｎｔＭａｓｋから、ｍｕｌｔｉＭａｓｋと、ｇｒａｎｔＭａｓｋとｈｏｌｄＭａｓｋの全ビットを反転した値の論理積とｍｕｌｔｉＭａｓｋの論理和に変更する（ＳＢ４’）。ｇｒａｎｔＭａｓｋとｈｏｌｄＭａｓｋの前ビットを反転した値との論理和を取ることにより、ｇｒａｎｔＭａｓｋにおいて自スレッドが獲得しているモードに対応するｂｉｔを０都市、強豪の判定条件から外すことが可能となる。なお、ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）が設定されている場合は少なくとも１つ以上の他スレッドがロックモードｍのロックを獲得していることを表しているので、ＳＢ４’では、無条件でｃｏｎｆｌｉｃｔ［ｍ］との論理積を取る。

同様の変更、すなわち、ｃｏｎｆｌｉｃｔ［ｍ］と論理積を取る値を、ｇｒａｎｔＭａｓｋから、ｍｕｌｔｉＭａｓｋと、ｇｒａｎｔＭａｓｋとｈｏｌｄＭａｓｋの全ビットを反転した値との論理積との論理和とする変更は、ＳＣ１０、ＳＡ４に対しても行ない、それぞれ、ＳＣ１０’、ＳＡ４’として図に示している。

更に、ＳＢ６からＳＢ９、すなわち、ロック状態ビットマスクに対するＣＡＳ操作が必要かどうかの判定、および、ＣＡＳ操作が必要な場合にＣＡＳ操作で使用する新値を作成する処理は、（１）ｇｒａｎｔＭａｓｋとｍｕｌｔｉＭａｓｋとの両方のｂｉｔ（ｍ）がセットされている場合は、ＣＡＳ操作不要（ｎｅｅｄＣＡＳをＦＡＬＳＥとする）、（２）ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）がセットされていると共にｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）がセットされていない場合には、ｎｅｅｄＣＡＳをＴＲＵＥ都市、新ｍｕｌｔｉＭａｓｋと旧ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）をセットした値とする、（３）ｇｒａｎｔＭａｓｋとｍｕｌｔｉＭａｓｋの両方のｂｉｔ（ｍ）がセットされていない場合には、ｎｅｅｄＣＡＳをＴＲＵＥとし、新ｇｒａｎｔＭａｓｋを旧ｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）をセットした値とするように変更する（ＳＢ６’、ＳＢ６''、Ｂ７’、Ｂ７''、Ｂ８’、Ｂ８''、Ｂ９’）。

ＳＣ６およびＳＡ１６では、Ｏｗｎｅｒ［ｍ］（ＳＡ１６ではＯｗｎｅｒ［ｗ］）の値を読みだした結果が０かどうかを判定していた。これは、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能なロック保持スレッド数の最大値である１未満であるかどうかを調べる条件判定であったが、本実施形態では、１ワードで表現可能なロック保持スレッド数の最大値が２となったことから、ＳＣ６およびＳＡ１６での判定は、「Ｏｗｎｅｒ［ｍ］（ＳＡ１６ではＯｗｎｅｒ［ｗ］）の値を読み出した結果が２未満かどうか」を調べる条件判定に変更する（ＳＣ６’、ＳＡ１６’）。

また、ロックを解放する処理については、ＳＲ１にて不可分減算によりＯｗｎｅｒ［ｍ］を１減らした結果をＳＲ２で０と比較していたが、これを１以下かどうかを判定する処理へと変更する（ＳＲ２’）。これは、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードにより、ロックを保持しているスレッド数を最大２まで表現できるようにしたことに対応する変更である。また、ＳＲ４では不可分演算（論理積）命令によりｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）をリセットしていたが、これを、不可分アクセスによりｍｕｌｔｉＭａｓｋもしくはｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）をリセットする処理へと変更する（ＳＲ４’）。ＳＲ４’に係るｍｕｌｔｉＭａｓｋもしくはｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）リセット処理は、図３０に示す。図３０を参照すると、この処理は、ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）がセットされている場合は（ＳＰ３のＮｏ）、ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）をリセット（ＳＰ５）、ｍｕｌｔｉＭａｓｋのｂｉｔ（ｍ）がセットされていない場合はｇｒａｎｔＭａｓｋのｂｉｔ（ｍ）をリセット（ＳＰ４）するＣＡＳ操作により行われる（ＳＰ６）。

（２．３ 本実施形態に係る効果）
以上説明した通り、本実施形態では、プロセッサが持つ不可分アクセス命令で扱うことのできる１ワードにより、ロックを保持しているスレッド数を最大２まで表現できるようにしたことにより、ロック・プロモーションの可能なロック方法を実現できる。

（３ 付記事項）
尚、前述の各実施形態の構成は、組み合わせたり或いは一部の構成部分を入れ替えたりしてもよい。また、本発明の構成は前述の実施形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加えてもよい。
尚、前述の各実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）
マルチプロセッサを有するロック管理システムであって、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ロック取得手段と、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理する管理手段とを備えるロック管理システム。

（付記２）
前記ロック取得手段は、前記第１の情報から、要求されたロックモードで取得しているスレッド数を調べる第１の手段と、当該スレッド数が前記第１の情報で表現可能な最大値未満の場合に、前記不可分アクセス命令により前記第１の情報の値を増加させると共に、前記マルチプロセッサの不可分演算命令により前記第２の情報の値を増加させる第２の手段と、前記スレッド数が前記第１の情報で扱うことのできる最大値以上の場合に、前記第２の情報の値を不可分アクセス命令により増加させる第３の手段とを備える、付記１記載のロック管理システム。

（付記３）
前記ロック取得手段は、前記第３の手段が前記第２の情報の値を増加させる際に、前記第２の情報を読み出した結果が前記第１の情報で表現可能な最大値未満の場合に、再度、前記第１の手段から処理を行う、付記２記載のロック管理システム。

（付記４）
前記第２の情報の値を前記不可分演算命令により減じると共に、当該減じた結果が前記第１の情報で扱う値の最大値未満の場合に、前記不可分演算命令により前記第１の情報の値を減じるロック解放手段、を更に備える付記１乃至付記３のいずれか１項記載のロック管理システム。

（付記５）
マルチプロセッサを有するロック管理システムのロック管理方法であって、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップとを備えるロック管理方法。

（付記６）
マルチプロセッサを有するロック管理システムに、１以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップとを実行させる、ロック管理用プログラム。

この出願は、２０１２年５月２３日に出願された日本出願特願２０１２−１１７６０５を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１・・・ロック管理システム、１００・・・プロセッサ、１１０・・・スレッド、２００・・・メモリ、３００・・・プログラム、３１０・・・ロック獲得処理、３２０・・・ロック解放処理、３３０・・・スレッド休眠処理、３４０・・・スレッド起床処理、４００・・・データ、４１０・・・ロック状態保持手段、４１１・・・ロック状態ビットマスク、４１３・・・カウンタ配列、４１５・・・待ち行列、４１７・・・ｍｕｔｅｘ、４２０・・・競合関係表、４３０・・・スレッド固有データ、４３１・・・ｈｏｌｄＭａｓｋ

Claims (6)

1. マルチプロセッサを有するロック管理システムであって、
   １以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ロック取得手段と、
   ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理する管理手段と
   を備えるロック管理システム。
2. 前記ロック取得手段は、
   前記第１の情報から、要求されたロックモードで取得しているスレッド数を調べる第１の手段と、
   当該スレッド数が前記第１の情報で表現可能な最大値未満の場合に、不可分アクセス命令により前記第１の情報の値を増加させると共に、前記マルチプロセッサの不可分演算命令により前記第２の情報の値を増加させる第２の手段と、
   前記スレッド数が前記第１の情報で扱うことのできる最大値以上の場合に、前記第２の情報の値を不可分アクセス命令により増加させる第３の手段と
   を備える、請求項１記載のロック管理システム。
3. 前記ロック取得手段は、前記第３の手段が前記第２の情報の値を増加させる際に、前記第２の情報を読み出した結果が前記第１の情報で表現可能な最大値未満の場合に、再度、前記第１の手段から処理を行う、
   請求項２記載のロック管理システム。
4. 前記第２の情報の値を不可分演算命令により減じると共に、当該減じた結果が前記第１の情報で扱う値の最大値未満の場合に、不可分演算命令により前記第１の情報の値を減じるロック解放手段、
   を更に備える請求項１乃至請求項３のいずれか１項記載のロック管理システム。
5. マルチプロセッサを有するロック管理システムのロック管理方法であって、
   １以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、
   ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップと
   を備えるロック管理方法。
6. マルチプロセッサを有するロック管理システムに、
   １以上のロックモードによりスレッドのロック取得処理を行ない、当該ロックモードの内、少なくとも一部のロックモードは、１以上のスレッドが取得可能な共有ロックである、ステップと、
   ロックを取得しているスレッド数を、前記マルチプロセッサが持つ不可分アクセス命令で扱うことのできる１ワードで表現可能な第１の情報と、各々のロックモードについてロックを取得する可能性のあるスレッド数の範囲全体を表現する第２の情報とで管理するステップと
   を実行させる、ロック管理用プログラム。

Images