ロックと並行処理の制御

ロック名

LOCK コマンドの引数の 1 つにロック名があります。ロック名は、任意の名前ですが、共通の規則として、プログラマはロックする項目の名前と同じロック名を使用します。通常、ロックする項目は、グローバルまたはグローバルのノードになります。したがって、通常ロック名は、グローバル名の名前またはグローバルのノードの名前のようになります。(このページでは、最も一般的であるキャレットで始まるロック名のみについて説明します。キャレットで始まらない名前のロックの詳細は、"ObjectScript リファレンス" の “LOCK” を参照してください。)

形式的には、ロック名は、"ObjectScript の使用法" の “変数” の章で説明したローカル変数およびグローバル変数と同じ名前付け規約に従います。変数と同様に、ロック名は大文字と小文字を区別し、添え字を付けることができます。プロセス・プライベート・グローバル名をロック名として使用しないでください (定義によってそのようなグローバルにアクセスできるプロセスは 1 つしかないため、そのようなロックは必要ありません)。

InterSystems IRIS によるメモリの割り当ておよび管理の方法により、ロック名の形式はパフォーマンスに影響します。ロックは、添え字を使用するロック名に対して最適化されます。例えば、^sample.person(id) です。

一方、InterSystems IRIS は、^name_concatenated_identifier のようなロック名に対しては最適化されません。添え字のないロック名を使用すると、ECP に関するパフォーマンスの問題の原因になる場合もあります。

ロック・テーブル

InterSystems IRIS は、現在のすべてのロックと、そのロックを所有しているプロセスを記録するために、システム規模のテーブルをメモリ内に保持しています。このテーブル (ロック・テーブル) は、管理ポータルからアクセスできます。管理ポータルでは、ロックの表示と、まれに必要になるロックの削除を実行できます。特定のプロセスが、ロック名が異なる複数のロックを所有している可能性がある点に注意してください (複数のロックが同じ名前の場合もあります)。

プロセスが終了すると、InterSystems IRIS は、そのプロセスが所有するすべてのロックを自動的に解放します。そのため、通常は、管理ポータルからロックを削除する必要はありません。ただし、アプリケーション・エラーが発生した場合を除きます。

ロック・テーブルは、固定サイズを超過することはありません (このサイズは locksiz 設定を使用して指定できます)。詳細は、"監視ガイド" の “ロックの監視” を参照してください。そのため、ロック・テーブルが一杯になり、それ以上のロックが不可能になることがあります。この場合、InterSystems IRIS は、messages.log ファイルに以下のエラー・メッセージを書き込みます。

LOCK TABLE FULL

通常は、ロック・テーブルが一杯になっても、アプリケーション・エラーとは見なされません。InterSystems IRIS には、ロック・キューも用意されているため、プロセスはロック・テーブルにロックを追加する領域ができるまで待機します。(ただし、デッドロックは、アプリケーションのプログラミング・エラーです。このページで後述の “デッドロックの回避” を参照してください。)

増分ロックの追加

ロックを追加するには、以下のように LOCK コマンドを使用します。

LOCK +lockname

lockname はリテラルのロック名です。プラス記号 (+) によって増分ロックが作成されます。これは一般的なシナリオです。一般的ではない代替手段は、“単純ロックの作成” を参照してください。

このコマンドは、以下を実行します。

1. 指定のロックをロック・テーブルに追加しようとします。つまり、このエントリはロック・キューに追加されます。

2. ロックを取得できるまで実行を一時停止します。

異なる動作をするさまざまなロック・タイプがあります。既定でないロック・タイプのロックを追加するには、以下のバリエーションを使用します。

LOCK +lockname#locktype

locktype は、二重引用符で囲んだロック・タイプ・コードの文字列です。後述の “ロック・タイプ” を参照してください。

特定のプロセスが同じ名前の複数の増分ロックを追加できる点に注意してください。これらのロックは異なるタイプにもすべて同じタイプにもできます。

タイムアウト付き増分ロックの追加

正しくない方法で増分ロックを使用すると、デッドロックと呼ばれる好ましくない状態になる可能性があります。デッドロックについては、後述する “デッドロックの回避” で説明します。デッドロックを回避する 1 つの方法は、ロック作成時にタイムアウト時間を指定することです。これを実行するには、以下のように LOCK コマンドを使用します。

LOCK +lockname#locktype :timeout

timeout は、タイムアウト時間の秒数です。コロンの前のスペースはオプションです。timeout に 0 を指定すると、InterSystems IRIS はロックの追加を 1 回試行します (ただし、以下の注意を参照してください)。

このコマンドは、以下を実行します。

1. 指定のロックをロック・テーブルに追加しようとします。つまり、このエントリはロック・キューに追加されます。

2. ロックを取得できるまでまたはタイムアウト時間が経過するまで、実行を一時停止します。

3. $TEST 特殊変数の値を設定します。ロックが取得されると、InterSystems IRIS は $TEST を 1 に設定します。それ以外の場合、InterSystems IRIS は $TEST を 0 に設定します。

つまり、タイムアウト引数を使用している場合、コードで $TEST 特殊変数の値を調べ、その値を使用して続行するかどうかを選択する必要があります。以下に例を示します。

 Lock +^ROUTINE(routinename):0 
 If '$TEST {  Return $$$ERROR("Cannot lock the routine: ",routinename)}

ロックの削除

既定のタイプのロックを削除するには、以下のように LOCK コマンドを使用します。

LOCK -lockname

このコマンドを実行するプロセスが特定の名前の (既定のタイプの) ロックを所有している場合、このコマンドによってそのロックが削除されます。または、そのプロセスが複数の (既定のタイプの) ロックを所有している場合、このコマンドによってそれらのロックの 1 つが削除されます。

別のタイプのロックを削除するには、以下のようにします。

LOCK -lockname#locktype

locktype は、ロック・タイプ・コードの文字列です。後述の “ロック・タイプ” を参照してください。ロック・タイプ・コードは、ロック作成時と同じ順序でなくてもかまいません。

LOCK コマンドの他の基本的なバリエーション

完全を期すために、ここでは LOCK コマンドの他の基本的なバリエーションについて説明します。LOCK コマンドを使用した単純ロックの作成と LOCK コマンドを使用したすべてのロックの削除です。これらのバリエーションは実際には一般的ではありません。

単純ロックの作成

LOCK コマンドでは、+ 演算子を省略すると、LOCK コマンドは、まずこのプロセスが保持している既存のロックをすべて削除し、新しいロックを追加しようとします。この場合のロックは、増分ロックではなく単純ロックと呼ばれます。プロセスが以下のような構文で複数の単純ロックをすべて同時に作成する場合、プロセスで複数の単純ロックを所有することが可能です。

 LOCK (^MyVar1,^MyVar2,^MyVar3)

複数のロックを保持し、コード内の異なるステップでそれらを取得する必要があることが多いため、単純ロックは実際には一般的ではありません。したがって、増分ロックを使用するほうが実用的です。

ただし、単純ロックが適切な場合、単純ロックの作成時に locktype 引数と timeout 引数を指定できます。また、単純ロックを削除するには、マイナス記号 (-) を付けて LOCK コマンドを使用できます。

排他ロックと共有ロック

あらゆるロックは、排他 (既定) または共有のどちらかになります。これらのタイプは、次に示す重要な意味を持ちます。

• あるプロセスが特定のロック名の付いた排他ロックを所有しているときに、その他のプロセスは、そのロック名の付いたロックを取得できません。

• あるプロセスが特定のロック名の付いた共有ロックを所有しているときに、その他のプロセスは、そのロック名の付いた共有ロックを取得できます。ただし、その他のプロセスはそのロック名の付いた排他ロックを取得できません。

排他ロックの一般的な目的は、値を変更する予定があることを示し、その他のプロセスがその値の読み取りまたは変更を試行してはいけないことを示すことです。共有ロックの一般的な目的は、値を読み取る予定があることを示し、その他のプロセスがその値の変更を試行してはいけないことを示すことです。ただし、その他のプロセスがその値を読み取ることは可能です。後述の “ロックの実際の使用方法” も参照してください。

非エスカレート・ロックとエスカレート・ロック

さらに、あらゆるロックは、非エスカレート (既定) またはエスカレートのどちらかになります。エスカレート・ロックの目的は、メモリを消費し、ロック・テーブルが埋め尽くされる可能性が大きくなる大量のロックの管理を簡単にすることです。

エスカレート・ロックは、同じ配列に含まれる複数のノードをロックする場合に使用します。エスカレート・ロックの場合、あるプロセスがある配列の並列ノードに特定の数 (既定では 1000) よりも多くのロックを作成すると、InterSystems IRIS は、個別のロック名を置き換えて、それらを新しい 1 つのロック (ロック・カウントを含むロック) に置き換えます (一方、InterSystems IRIS は非エスカレート・ロックに対してはこの動作を行いません)。詳細と使用例は、後述の “エスカレート・ロック” を参照してください。

ロック・タイプのまとめ

以下の表に可能なすべてのロック・タイプとその説明を示します。

複数のロック・コードを使用するロック・タイプの場合、ロック・コードの順序は任意にできます。例えば、ロック・タイプ #"SI" と #"IS" は同じです。

即時アンロックと遅延アンロックの詳細は、"ObjectScript リファレンス" の "LOCK" を参照してください。同じロック名に対してこれら 2 つのロック・タイプ・コードを同時に使用することはできません。

ロックのエスカレーションの例

^MyGlobal("sales",EU",salesdate) という形式で salesdate が日付を表しているロックが 1000 個あるとします。ロック・テーブルは以下のようになります。

所有者 19776 のエントリに注目してください (これはロックを所有するプロセスです)。[モードカウント] 列は、これらが共有のエスカレート・ロックであることを示しています。

同じプロセスが同じ形式の別のロックを作成しようとすると、InterSystems IRIS はこれらをエスカレートします。これらのロックを削除し、^MyGlobal("sales","EU") という名前の単一のロックで置き換えます。ロック・テーブルは以下のようになります。

[モードカウント] 列は、これが共有のエスカレート・ロックで、そのカウントが 1001 であることを示しています。

以下の重要な点に注意してください。

• ^MyGlobal("sales","EU") のすべての子ノードは、この時点で配列ロックの基本的な規則に従って暗黙的にロックされます。

• ロック・テーブルには、^MyGlobal("sales","EU") のどの子ノードが具体的にロックされたかに関する情報が含まれなくなります。これは、ロックを削除する際に重要な意味を持ちます。次のサブセクションを参照してください。

同じプロセスが ^MyGlobal("sales","EU",salesdate) の形式のロック名をさらに追加すると、ロック・テーブルは、ロック名 ^MyGlobal("sales","EU") のロック・カウントをインクリメントします。ロック・テーブルは以下のようになります。

[モードカウント] 列は、このロックのロック・カウントが 1026 になったことを示しています。

エスカレート・ロックの削除

非エスカレート・ロックと正確に同じ方法で、アプリケーションは、特定の子ノードのロックをできるだけ早く解放する必要があります。これを行うと、InterSystems IRIS は、エスカレートされたロックのロック・カウントをデクリメントします。例えば、コードが ^MyGlobal("sales","EU",salesdate) のロックを削除したとします (salesdate は 2011 年の任意の日付に対応し、したがって 365 個のロックが削除されます)。ロック・テーブルは以下のようになります。

ロックの数がしきい値 (1000) 未満になったにもかかわらず、ロック・テーブルには ^MyGlobal("sales","EU",salesdate) のロックの個別のエントリが含まれていないことがわかります。

ノード ^MyGlobal("sales") は、プロセスが ^MyGlobal("sales","EU",salesdate) の形式のロックをさらに 661 個削除するまで明示的にロックされたままです。

シナリオ 1 ：同じグローバル・データベースを持つ複数のネームスペース

前述のとおり、プロセス A が特定のロック名の付いた排他ロックを所有しているときに、その他のプロセスは、同じロック名の付いたロックを取得できません。

ロック名がキャレットで始まる場合、この規則は、同じグローバル・データベースを使用するすべてのネームスペースに適用されます。

例えば、ネームスペース ALPHA と BETA の両方がデータベース GAMMA をグローバル・データベースとして使用するように構成されているとします。以下は、部分的な例です。

次に以下のシナリオを考えてみます。

1. ネームスペース ALPHA では、プロセス A が ^MyGlobal(15) という名前の排他ロックを取得します。

2. ネームスペース BETA では、プロセス B が ^MyGlobal(15) という名前のロックを取得しようとします。この LOCK コマンドは復帰しません。このプロセスは、プロセス A がロックを解放するまでブロックされます。

このシナリオでは、プロセス A が所有するロックのエントリのみがロック・テーブルに含まれています。ロック・テーブルを調べると、このロックの適用先の データベース を示していることがわかります。 [ディレクトリ] 列を参照してください。例えば以下のようになります。

シナリオ 2 ：ネームスペースがマップされたグローバルを使用

1 つまたは複数のネームスペースにグローバル・マッピングが含まれている場合、システムは、該当のネームスペースにわたってロック・メカニズムを自動的に強制適用します。InterSystems IRIS は、既定以外のネームスペースでロックが取得されると、追加のロック・テーブル・エントリを自動的に作成します。

例えば、ネームスペース ALPHA がデータベース ALPHADB をグローバル・データベースとして使用するように構成されているとします。また、ネームスペース BETA が異なるデータベース (BETADB) をグローバル・データベースとして使用するように構成されているとします。ネームスペース BETA には、^MyGlobal が ALPHADB データベースに格納されることを指定するグローバル・マッピングも含まれています。以下は、部分的な例です。

次に以下のシナリオを考えてみます。

1. ネームスペース ALPHA では、プロセス A が ^MyGlobal(15) という名前の排他ロックを取得します。

   前述のシナリオと同様に、プロセス A が所有するロックのエントリのみがロック・テーブルに含まれています。このロックは ALPHADB データベースに適用されます。

   

2. ネームスペース BETA では、プロセス B が ^MyGlobal(15) という名前のロックを取得しようとします。この LOCK コマンドは復帰しません。このプロセスは、プロセス A がロックを解放するまでブロックされます。

シナリオ 3 ：ネームスペースがマップされたグローバル添え字を使用

添え字レベル・マッピングを使用するグローバル・マッピングが 1 つまたは複数のネームスペースに含まれている場合、システムは、該当のネームスペースにわたってロック・メカニズムを自動的に強制適用します。この場合、InterSystems IRIS は、既定以外のネームスペースでロックが取得されると、追加のロック・テーブル・エントリを自動的に作成します。

例えば、ネームスペース ALPHA がデータベース ALPHADB をグローバル・データベースとして使用するように構成されているとします。ネームスペース BETA は BETADB データベースをグローバル・データベースとして使用します。

また、ネームスペース BETA には、^MyGlobal(15) が ALPHADB データベースに格納される (一方、このグローバルの残りはネームスペースの既定の場所に格納される) ように添え字レベルのグローバル・マッピングも含まれているとします。以下は、部分的な例です。

次に以下のシナリオを考えてみます。

1. ネームスペース ALPHA では、プロセス A が ^MyGlobal(15) という名前の排他ロックを取得します。

   前述のシナリオと同様に、プロセス A が所有するロックのエントリのみがロック・テーブルに含まれています。このロックは ALPHADB データベース (c:\InterSystems\IRIS\mgr\alphadb など) に適用されます。

2. ネームスペース BETA では、プロセス B が ^MyGlobal(15) という名前のロックを取得しようとします。この LOCK コマンドは復帰しません。このプロセスは、プロセス A がロックを解放するまでブロックされます。

既定以外のネームスペースがロックを取得しても全体的な動作は同じですが、InterSystems IRIS による詳細の処理は若干異なります。ネームスペース BETA で、あるプロセスが ^MyGlobal(15) という名前のロックを取得するとします。この場合、ロック・テーブルには 2 つのエントリが含まれます。1 つは ALPHADB データベース用、もう 1 つは BETADB データベース用です。これらのロックは、両方ともネームスペース BETA のプロセスによって所有されます。

このプロセスがロック名 ^MyGlobal(15) を解放すると、システムは両方のロックを自動的に削除します。

シナリオ 4 ：拡張グローバル参照

1 つのネームスペースで実行されているコードは、拡張参照を使用して、拡張参照を使用しない場合にはこのネームスペースでは使用できないグローバルにアクセスできます。この場合、InterSystems IRIS は、関連するデータベースに影響するロック・テーブルにエントリを追加します。このロックは、これを作成したプロセスに所有されます。例えば、以下のシナリオを考えてみます。わかりやすくするために、このシナリオにはグローバル・マッピングはありません。

1. プロセス A は ALPHA ネームスペースで実行されていて、このプロセスは以下のコマンドを使用して、BETA ネームスペースで使用できるグローバルでロックを取得します。

    lock ^["beta"]MyGlobal(15)

   

2. ここで、ロック・テーブルには以下のエントリが含まれています。

   

   これはグローバル名のみを示していることに注意してください (これにアクセスするために使用する参照ではありません)。また、このシナリオでは、BETADB は BETA ネームスペースの既定のデータベースです。

3. ネームスペース BETA では、プロセス B が ^MyGlobal(15) という名前のロックを取得しようとします。この LOCK コマンドは復帰しません。このプロセスは、プロセス A がロックを解放するまでブロックされます。

プロセス・プライベート・グローバルは技術的には拡張参照の一種ですが、InterSystems IRIS は、プロセス・プライベート・グローバル名をロック名として使用することをサポートしていません。定義によってそのようなグローバルにアクセスできるプロセスは 1 つしかないため、そのようなロックは必要ありません。

アプリケーション・データへのアクセスの制御

ロックは、グローバルに格納されているアプリケーション・データへのアクセスを制御するために使用されることが非常に多いです。アプリケーションは、このデータの特定の一部を読み取りまたは変更する必要があり、これを行う前に以下のように 1 つまたは複数のロックを作成する場合があります。

• アプリケーションが 1 つまたは複数のグローバル・ノードを読み取る必要があり、読み取り操作中に他のプロセスがこの値を変更しないようにする場合、これらのノードの共有ロックを作成します。

• アプリケーションが 1 つまたは複数のグローバル・ノードを変更する必要があり、変更中に他のプロセスがこれらのノードを読み取らないようにする場合、これらのノードの排他ロックを作成します。

その後、計画どおりに読み取りまたは変更を行います。完了したら、ロックを削除します。

ロック・メカニズムは純粋に規約によって動作することに注意してください。これらのノードの読み取りまたは変更を行う他のコードも、これらの操作を実行する前にロックを取得しようとする必要があります。

同時アクティビティの防止

ロックは、複数のプロセスが同じアクティビティを実行することを防止するためにも使用されます。このシナリオでは、グローバルも使用しますが、そのグローバルには、純粋なアプリケーション・データではなくアプリケーションの内部用データが含まれています。単純な例として、どのような場合でも複数のプロセスで実行されてはいけないルーチン (^NightlyBatch) があるとします。このルーチンは、処理のごく初期段階に以下のことを実行できます。

1. 特定のグローバル・ノードに排他ロックを作成します (例えば、^AppStateData("NightlyBatch"))。この操作にタイムアウトを指定します。

2. ロックが取得された場合、グローバルにノードを設定し、ルーチンが開始されたこと (および他の関連情報) を記録します。例えば以下のようになります。

    set ^AppStateData("NightlyBatch")=1
    set ^AppStateData("NightlyBatch","user")=$USERNAME

   

   タイムアウト時間内にロックが取得されなかった場合、このルーチンが既に開始されていることを示すエラー・メッセージで終了します。

処理の最後に、同じルーチンが該当のグローバル・ノードをクリアし、ロックを解放します。

以下の部分的な例はこの方法を示しています。これは、InterSystems IRIS が内部的に使用するコードから採用されています。

  lock ^AppStateData("NightlyBatch"):0
  if '$TEST {
     write "You cannot run this routine right now."
     write !, "This routine is currently being run by user: "_^AppStateData("NightlyBatch","user")
     quit
  }
  set ^AppStateData("NightlyBatch")=1
  set ^AppStateData("NightlyBatch","user")=$USERNAME
  set ^AppStateData("NightlyBatch","starttime")=$h
  
  //main routine activity omitted from example
  
  kill ^AppStateData("NightlyBatch")
  lock -^AppStateData("NightlyBatch")