第17章 スレッドおよびロック

待機アクションは、wait()の起動時、またはwait(long millisecs)およびwait(long millisecs, int nanosecs)の時間指定フォームで発生します。

パラメータがゼロのwait(long millisecs)の呼出し、または2つのゼロ・パラメータを持つwait(long millisecs, int nanosecs)の呼出しは、wait()の呼出しと同等です。

スレッドは、InterruptedExceptionをスローせずに戻ると、待機から通常どおり戻ります。

スレッドtをオブジェクトmでwaitメソッドを実行するスレッドとし、nをtによるmに対するロック・アクションの数とし、ロック解除アクションでは一致しません。 次のいずれかが発生します。

通知アクションは、メソッドnotifyおよびnotifyAllの起動時に発生します。

スレッドtをオブジェクトmでこれらのメソッドのいずれかを実行しているスレッドにし、nをmのtによるロック・アクションの数とし、ロック解除アクションでは一致しません。 次のいずれかが発生します。

中断アクションは、Thread.interruptの起動時に発生し、ThreadGroup.interruptなど、Thread.interruptを順番に起動するように定義されたメソッドも発生します。

tをu.interruptを起動するスレッドとし、一部のスレッドuの場合はtとuが同じ場合もあります。 このアクションにより、uの中断ステータスがtrueに設定されます。

また、待機セットにuが含まれるオブジェクトmが存在する場合、uはmの待機セットから削除されます。 これにより、uは待機アクションで再開できます。この場合、この待機は、mのモニターを再ロックした後、InterruptedExceptionをスローします。

Thread.isInterruptedを起動すると、スレッドの中断ステータスを判断できます。 staticメソッドThread.interruptedは、スレッドによって起動され、独自の中断ステータスを監視およびクリアできます。

前述の仕様により、待機、通知および中断の相互作用に関係する複数のプロパティを決定できます。

スレッドが通知され、待機中に中断された場合、次のいずれかになります。

スレッドは、その割り込みステータスをリセットできず、waitへのコールから正常に戻す場合があります。

同様に、割込みによって通知が失われることはありません。 あるスレッドのセットがオブジェクトmの待機セット内にあり、別のスレッドがmに対してnotifyを実行するとします。 次に、いずれかを実行します。

スレッドが中断され、notifyを介して呼び出され、そのスレッドがInterruptedExceptionをスローしてwaitから戻った場合は、待機セット内の他のスレッドに通知する必要があります。

スレッド間で共有できるメモリーは、共有メモリーまたはヒープ・メモリーと呼ばれます。

すべてのインスタンス・フィールド、staticフィールドおよび配列要素は、ヒープ・メモリーに格納されます。 この章では、変数という用語は、フィールドと配列要素の両方を指す場合に使用します。

ローカル変数(§14.4)、仮メソッド・パラメータ(§8.4.1)、例外ハンドラ・パラメータ(§14.20)はスレッド間で共有されることはなく、メモリー・モデルによって影響を受けません。

同じ変数への2つのアクセス(読取りまたは書込み)は、少なくとも1つのアクセスが書込みである場合、競合と見なされます。

スレッド間アクションは、あるスレッドによって実行されるアクションで、別のスレッドによって検出または直接影響を受けます。 プログラムが実行できるスレッド間アクションには、いくつかの種類があります。

この仕様は、スレッド間アクションにのみ関係します。 スレッド内アクション(たとえば、2つのローカル変数を追加し、その結果を3番目のローカル変数に格納する)を気にする必要はありません。 前述のように、すべてのスレッドは、Javaプログラムの正しいスレッド内セマンティクスに従う必要があります。 通常、スレッド間アクションをより簡潔にアクションと呼びます。

アクションaは、次のタプル< t、k、v、u>によって記述されます。

外部アクション・タプルには、アクションを実行するスレッドによって認識される外部アクションの結果を含む追加のコンポーネントが含まれます。 これは、アクションの成功または失敗に関する情報、およびアクションによって読み取られる任意の値です。

外部アクションのパラメータ(ソケットに書き込まれるバイトなど)は、外部アクション・タプルの一部ではありません。 これらのパラメータは、スレッド内の他のアクションによって設定され、スレッド内セマンティクスを調べることによって決定できます。 これらはメモリー・モデルでは明示的に説明されません。

終了していない実行では、すべての外部アクションが監視できるわけではありません。 終了しない実行および監視可能なアクションについては、§17.4.9で説明します。

各スレッドtによって実行されるすべてのスレッド間アクションの中で、tのプログラム順序は、tのスレッド内セマンティクスに従ってこれらのアクションが実行される順序を反映した合計順序です。

すべてのアクションがプログラム順序と一致する合計順序(実行順序)で発生し、さらに変数vの各読取りrによってvに書き込まれた値がwからvに書き込まれる場合、一連のアクションは順次一貫性があります。

順次一貫性は、プログラムの実行における可視性と順序付けに関して非常に強力な保証です。 順次一貫した実行内では、プログラムの順序と一致する個々のアクション(読取りや書込みなど)すべてに合計順序があり、個々のアクションはアトミックであり、すべてのスレッドに即時に表示されます。

プログラムにデータ競合がない場合、プログラムのすべての実行は順次一貫しているように見えます。

データ競合からの順次一貫性または自由度(あるいはその両方)によって、不可分に認識される必要があり、認識されない操作のグループから発生するエラーが依然として許容されます。

メモリー・モデルとして順次整合性を使用する場合、これまでに説明したコンパイラおよびプロセッサの最適化の多くは違法です。 たとえば、表17.4-Cのトレースでは、p.xへの3の書込みが発生するとすぐに、その値を確認するためにその場所の後続の読取りが必要になります。

すべての実行に同期順序があります。 同期順序は、実行のすべての同期アクションの合計順序です。 スレッドtごとに、tの同期アクション(§17.4.2)の同期順序は、tのプログラム順序(§17.4.3)と一致します。

同期アクションは、次のように定義されたアクションに対してsynchronized-withリレーションを誘導します。

synchronizes-withエッジのソースをリリースと呼び、宛先を取得と呼びます。

happens-before関係では、2つのアクションを順序付けできます。 happens-beforeアクションが別のアクションの場合、最初のアクションは2番目のアクションに対して表示され、2番目のアクションより前に順序付けられます。

2つのアクションxおよびyがある場合は、hb(x、 y)を記述して、x happen-before yを示します。

クラスObjectのwaitメソッド(§17.2.1)には、それらに関連付けられたロックおよびロック解除アクションがあります。それらのhappens-before関係は、これらの関連アクションによって定義されます。

2つのアクション間にhappens-before関係が存在することは、必ずしも実装内でその順序で実行する必要があることを意味するものではありません。 順序変更によって法的実行と一致する結果が生成される場合、それは違法ではありません。

たとえば、スレッドによって構築されたオブジェクトのすべてのフィールドへのデフォルト値の書込みは、そのスレッドの開始前に行う必要はありません。ただし、読取りによってその事実が観測されることはありません。

具体的には、2つのアクションがhappens-before関係を共有する場合、happens-before関係を共有しないコードに対して、その順序で発生したとはかぎりません。 たとえば、あるスレッドで、別のスレッドでの読み取りと競合している書き込みは、それらの読み取りに対して順不同のように見えることがあります。

happens-beforeリレーションは、データの競合が発生するタイミングを定義します。

一連の同期エッジ(S)は、プログラム順序によるSの推移的クローズによって実行のhappens-beforeエッジがすべて決定されるように、最小セットである場合は十分です。 このセットは一意です。

前述の定義から、次のことを行います。

プログラムに2つの競合するアクセス(§17.4.1)が含まれていて、前回の関係では順序付けられていない場合、データ競合が含まれていると言われています。

配列長の読取り(§10.7)、チェックされたキャストの実行(§5.5、§15.16)、仮想メソッドの呼出し(§15.12)など、スレッド間アクション以外の操作のセマンティクスは、データの競合によって直接影響を受けません。

したがって、データの競合によって、配列に誤った長さを返すなどの誤った動作が発生することはありません。

プログラムが正しく同期されるのは、順次一貫性のあるすべての実行でデータの競合が発生していない場合のみです。

プログラムが正しく同期されている場合、プログラムのすべての実行は順次一貫しているように見えます(§17.4.3)。

これはプログラマーにとって非常に強力な保証です。 プログラマは、コードにデータの競合が含まれているかどうかを判断するために、並べ替えを理由にする必要はありません。 したがって、コードが正しく同期されているかどうかを判断する際に、順序変更について理由を付ける必要はありません。 コードが正しく同期されていると判断すると、プログラマは順序変更によってコードが影響を受けることを心配する必要はありません。

コードの順序変更時に監視できる直観的な動作の種類を回避するために、プログラムを正しく同期させる必要があります。 正しい同期を使用すると、プログラムの全体的な動作が正しいとはかぎりません。 ただし、その使用により、プログラマはプログラムの考えられる動作を単純な方法で推論できます。正しく同期されたプログラムの動作は、考えられる順序変更に大きく依存しません。 正しい同期がないと、非常に奇妙でわかりにくく、直観的な動作が可能になります。

変数 vの読み取り rは、実行トレースの happens-before部分的な順序で vへの書き込み wを観察できます。

非公式には、happens-beforeの順序付けがない場合に、読取りrが書込みwの結果を参照して、その読取りを防止できます。

Aの一連のアクションは、happens-before consistentであり、すべての読取りrがAの場合、W(r)はrによって確認された書込みアクションであり、hb(r、W(r))、またはwがAに存在し、w.v = r.vおよびhb(W(r)、w)およびhb(w、r)の場合ではありません。

happens-before consistentアクション・セットでは、各読取りで、happens-before順序付けによって表示が許可されている書込みが認識されます。

1: B = 1;
3: A = 2;
2: r2 = A;  // sees initial write of 0
4: r1 = B;  // sees initial write of 0

1: r2 = A;  // sees write of A = 2
3: r1 = B;  // sees write of B = 1
2: B = 1;
4: A = 2;

実行Eは、タプル< P、 A、 po、 so、 W、 V、 sw、 hb>によって記述され、次のもので構成されます。

synchronizes-with要素とhappen-before要素は、実行の他のコンポーネントおよび整形式実行のルールによって一意に決定されることに注意してください(§17.4.7)。

一連のアクションがhappens-before consistent(§17.4.5)の場合、実行はhappens-before consistentです。

整形式の実行のみを考慮します。 実行E = < P、 A、 po、 so、 W、 V、 sw、 hb >は、次の条件を満たす場合に適切に形成されます。

f|_dは、fのドメインを dに制限することによって与えられた関数を示すために使用します。 dのすべてのx、f|_d(x) = f(x)およびxのすべてのd、f|_d(x)は未定義です。

p|_dは、d内の要素に対する部分的な順序pの制限を表すために使用します。 すべてのx、dのy、p(x、y) (p|_d(x、y)の場合のみ。 xまたはyのいずれかがdにない場合、p|_d(x、y)には該当しません。

整形式の実行E = < P、 A、 po、 so、 W、 V、 sw、 hb >は、Aからのコミット・アクションによって検証されます。 Aのすべてのアクションをコミットできる場合、実行はJavaプログラミング言語メモリー・モデルの原因要件を満たします。

空のセットからC₀として、一連のアクションAからアクションを実行し、コミットされたアクションのセットC_iに追加して、コミットされたアクションの新しいセットC_i+1を取得します。 これが妥当であることを実証するには、C_iごとに、特定の条件を満たすCiを含む実行Eを示す必要があります。

実行Eは、次のものが存在する場合にのみ、Javaプログラミング言語メモリー・モデルの因果関係の要件を満たします。

これらの一連のアクション C₀、...、および実行 E₁ ...を考慮すると、C_i内のすべてのアクションは E_i内のアクションの1つである必要があります。 C_iのすべてのアクションは、E_iとEの両方で、オーダー前と同じ相対的な順序および同期順序を共有する必要があります。 正式に:

C_iでの書込みによって書き込まれる値は、E_iとEの両方で同じである必要があります。 _Ci-1の読取りのみが、E_Eと同じ書込みをEで表示する必要があります。 正式に:

_iでC_i-1に含まれていないすべての読取りで、その前に発生した書込みが表示される必要があります。 Ci - C_i-1の各読取りrでは、E_iとE_Eの両方にEの書込みが表示されていますが、E_iの書込みがEに表示される書込みとは異なる場合があります。 正式に:

E_iの十分なsynchronizes-withエッジがある場合、コミットするアクションの前に発生するリリース取得ペア(§17.4.5)がある場合、そのペアはすべてのE_jに存在する必要があります(j ≥ i)。 正式に:

r1 = x;  // sees write of x = 1
y = 1;
r2 = y;  // sees write of y = 1
x = 1;

制限された有限期間内に常に終了するプログラムの場合、その動作は、許容される実行に関して単純に(公式に)理解できます。 制限された時間内に終了できないプログラムの場合、より微妙な問題が発生します。

プログラムの観察可能な動作は、プログラムが実行できる外部アクションの有限セットによって定義されます。 たとえば、「Hello」を永久に出力するプログラムは、負でない整数 iに対して「Hello」を i回出力する動作を含む一連の動作によって記述されます。

終了は動作として明示的にモデル化されませんが、プログラムを簡単に拡張して、すべてのスレッドが終了したときに発生する追加の外部アクションexecutionTerminationを生成できます。

また、特別なハング・アクションも定義します。 動作がハング・アクションを含む一連の外部アクションによって記述されている場合、外部アクションが観察された後に、プログラムは追加の外部アクションを実行したり終了することなく、無制限の時間実行できる動作を示します。 すべてのスレッドがブロックされている場合、またはプログラムが外部アクションを実行せずに無制限の数のアクションを実行できる場合は、プログラムをハングアップできます。

スレッドは、ロックを取得しようとしたり、外部データに依存する外部アクション(読み取りなど)を実行しようとする場合など、さまざまな状況でブロックできます。

実行によって、スレッドが無期限にブロックされ、実行が終了しない場合があります。 このような場合、ブロックされたスレッドによって生成されるアクションは、スレッドがブロックされる原因となったアクションまで、そのスレッドによって生成されたすべてのアクションと、そのアクションの後にスレッドによって生成されるアクションを含めて構成する必要があります。

観察可能な行動を推論するには、一連の観察可能な行動について話す必要があります。

Oが実行Eの観察可能なアクションのセットである場合、OはEのアクション(A)のサブセットである必要があり、Aに無限の数のアクションが含まれている場合でも、有限数のアクションのみを含める必要があります。 さらに、アクションyがOにあり、hb(x、 y)またはso(x、 y)のいずれかである場合、xはOになります。

一連の監視可能なアクションは、外部アクションに制限されないことに注意してください。 むしろ、観察可能な一連のアクションに含まれる外部アクションのみが、観察可能な外部アクションとみなされます。

動作Bは、Bが外部アクションの有限セットであり、次のいずれかの場合にのみ、プログラムPの許容可能な動作です。

動作Bでは、Bの外部アクションが観察される順序は説明されませんが、外部アクションの生成方法および実行方法に関するその他の(内部)制約では、このような制約が課される可能性があります。

oをオブジェクトとし、cを、finalフィールドfが書き込まれるoのコンストラクタにします。 cが正常にまたは突然終了すると、oのfinalフィールドfに対するfreezeアクションが実行されます。

あるコンストラクタが別のコンストラクタを起動し、呼び出されたコンストラクタがfinalフィールドを設定すると、呼び出されたコンストラクタの最後にfinalフィールドのフリーズが発生することに注意してください。

実行ごとに、読取りの動作は、2つの追加部分順序(間接参照チェーンdereferences()とメモリー・チェーンmc())の影響を受けます。これらは、実行の一部とみなされます(したがって、特定の実行に対して固定されます)。 これらの部分オーダーは、次の制約を満たす必要があります(一意のソリューションを使用する必要はありません)。

書き込み w、フリーズ f、アクション a (finalフィールドの読み取りではない)、_fによってフリーズされた finalフィールドの r1、および読み取り r₂が hb()w、f)、hb(f、a)、mc(a、r₁)、および dereferences(r₁、r₂)で、r₂で確認できる値を判断する際には、hb(w、 r₂)について検討します。 (このhappens-before順序付けは、他のhappens-before順序付けと遷移的にクローズしません。)

dereferencesの順序は反射的であり、r₁は r₂と同じにすることができます。

finalフィールドの読取りの場合、finalフィールドの読取り前に存在するとみなされる書込みは、finalフィールド・セマンティクスによって導出された書込みのみです。

通常のhappens-beforeルールによるコンストラクタ内のそのフィールドの初期化に関して、そのオブジェクトを構成するスレッド内のオブジェクトのfinalフィールドの読取り。 コンストラクタでフィールドが設定された後に読取りが発生すると、finalフィールドが割り当てられた値が表示され、それ以外の場合はデフォルト値が表示されます。

デシリアライズなど、場合によっては、構築後にオブジェクトのfinalフィールドを変更する必要があります。finalフィールドは、リフレクションやその他の実装に依存する手段によって変更できます。 これが妥当なセマンティクスを持つ唯一のパターンは、オブジェクトが構築されてから、オブジェクトのfinalフィールドが更新されるパターンです。 このオブジェクトは、オブジェクトのfinalフィールドに対するすべての更新が完了するまで、他のスレッドから参照できるようにしたり、finalフィールドを読み取ることはできません。 finalフィールドのフリーズは、finalフィールドが設定されているコンストラクタの末尾と、リフレクションまたはその他の特別なメカニズムによるfinalフィールドの変更の直後の両方で発生します。

それでも、いくつかの合併症があります。 finalフィールドがフィールド宣言で定数式(§15.29)に初期化されている場合、finalフィールドへの変更は監視されないことがあります。これは、そのfinalフィールドの使用は、コンパイル時に定数式の値に置き換えられるためです。

もう1つの問題は、仕様でfinalフィールドを積極的に最適化できることです。 スレッド内では、コンストラクタ内で行われないfinalフィールドの変更を使用して、finalフィールドの読取りを並べ替えることができます。

class A {
    final int x;
    A() {
        x = 1;
    }

    int f() {
        return d(this,this);
    }

    int d(A a1, A a2) {
        int i = a1.x;
        g(a1);
        int j = a2.x;
        return j - i;
    }

    static void g(A a) {
        // uses reflection to change a.x to 2
    }
}

実装は、final-field-safeコンテキストでコードのブロックを実行する方法を提供できます。 オブジェクトがfinal-field-safeコンテキスト内に構築されている場合、そのオブジェクトのfinalフィールドの読取りは、そのfinal-field-safeコンテキスト内で発生するfinalフィールドの変更によって並べ替えられません。

finalフィールド・セーフ・コンテキストには、追加の保護があります。 スレッドがfinalフィールドのデフォルト値を参照できるオブジェクトへの参照を誤って公開し、finalフィールド・セーフ・コンテキスト内でオブジェクトへの適切な公開済参照を読み取ると、finalフィールドの正しい値を確認することが保証されます。 形式主義では、finalフィールド・セーフ・コンテキスト内で実行されるコードは、個別のスレッドとして扱われます(finalフィールド・セマンティクスの目的のみ)。

実装では、コンパイラはfinalフィールドへのアクセスをfinalフィールド・セーフ・コンテキストの内外に移動しないでください(ただし、そのコンテキスト内でオブジェクトが構築されていないかぎり、そのようなコンテキストの実行を中心に移動できます)。

finalフィールド・セーフ・コンテキストの使用が適している場所の1つは、エグゼキュータまたはスレッド・プールにあります。 エグゼキュータは、各Runnableを個別のfinalフィールド・セーフ・コンテキストで実行することで、1つのRunnableによるオブジェクトoへの不正なアクセスによって、同じエグゼキュータによって処理される他のRunnableのfinalフィールドが保証されないことを保証できます。

通常、finalおよびstaticのフィールドは変更できません。 ただし、System.in、System.outおよびSystem.errはstatic finalフィールドであり、従来の理由から、メソッドSystem.setIn、System.setOutおよびSystem.setErrによる変更を許可する必要があります。 これらのフィールドを、通常のfinalフィールドと区別するために書込み保護と呼びます。

コンパイラは、これらのフィールドを他のfinalフィールドとは異なる方法で処理する必要があります。 たとえば、通常のfinalフィールドの読取りは同期の「免疫」です。ロックまたは揮発性読取りに関係するバリアは、finalフィールドから読み取られる値に影響を与えません。 書き込み保護されたフィールドの値は変更される可能性があるため、同期イベントはそれらに影響を与えます。 したがって、セマンティクスでは、これらのフィールドは、ユーザー・コードがSystemクラス内にないかぎり、ユーザー・コードで変更できない通常のフィールドとして扱われることを規定しています。