なぜテストと設定のコンセンサス番号は2なのですか？

ウィキペディアによると、

テストおよび設定操作は、2つ以下の同時プロセスの待機なしのコンセンサス問題を解決できます。

3つ以上のプロセスで問題を解決できないのはなぜですか？

同じページにいることを確認するために、まずこれら3つの定義を検討します。

定義。Test-and-setは、スレッドが古い値を取得して1を書き込むバイナリレジスタ（0と1が可能な値であると言うだけです）での読み取り-変更-書き込み命令です。

定義。すべてのnスレッドが同じ値（整合性要件）を決定し、すべてのスレッドが実際にスレッドの1つによって提案された値（有効性要件）を決定する場合、スレッド間で合意に達します。$n$$n$

定義。すべてのメソッド呼び出しが有限数のステップで終了する場合、コンセンサスプロトコルは待機なしです。

次に、2つのプルーフスケッチに従います。

主張1.テストセットのコンセンサス数は少なくとも2です。証明。コンセンサスに達する必要がある2つのスレッド0と1があるとします。これを行うには、各スレッドを以下のコンセンサスプロトコルに従うようにします。

1. 提案された値をに書き込みます。tはスレッドID、Aはサイズ2の配列です。$A[t]$$t$$A$
2. Rを0に初期化して、レジスタでテストおよび設定命令を実行します。$R$$R$
3. 戻り値が0の場合、最初はreturn です。それ以外の場合、2番目でした：A [ |を返します t − 1 | ]。$A[t]$$A[|t-1|]$

コンセンサスと待機フリーが満たされていることを確認できます。$\square$

（次の証明のために、いくつかの証明と定義を入れ子にします。これは、従うのが簡単になると思うからです。）

主張2.テストとセットのコンセンサス数は最大2です。証明。矛盾によって。値a、b、cをそれぞれ決定したい3つのスレッド、B、Cがあり、テストとセット（およびアトミックな読み取りと書き込みを使用して実装された有効な待機フリー合意プロトコルがあると仮定します。 ）。$A$$B$$C$$a$$b$$c$

コンセンサスプロセスを有向木として視覚化できます。

• ルートとは、どのスレッドも「移動」していない状態です。
• ノードの左の子は、移動後に生じる状態を表し、中央の子は、Bの移動後に生じる状態を表し、右の子は、Cによる移動後に生じる状態を表します。$A$$B$$C$
• リーフノードは、すべてのスレッドが終了した状態を表します。リーフノードに関連付けられている値は、値、b、またはcです。値は、その特定の実行に対して決定された値によって異なります。$a$$b$$c$

定義。コンセンサスプロセスの結果がまだ決定されていない場合、状態を多価にします。言い換えれば、残りの動きのすべての可能なインターリーブが同じ結果をもたらすわけではありません。コンセンサスプロセスの結果が決定されると、状態は一価になります。

ルートは多価です。 証明。1つのスレッドのみがアクティブで、他のスレッドが永久に休止状態にある場合、Xは有限数のステップで終了し（待機フリーネスの仮定により保証されます）、xを決定します（この値とその値にのみアクセスできるため）決定はコンセンサス妥当性要件を満たします）。したがって、私たちの状況では、a、b、cはすべて可能な結果です。$X$$X$$x$$a$$b$$c$$\square$

定義。臨界状態にすることによって移動することの追加の特性を有する、多価である状態とする決定するであろう、とによって移動Bが決定するbは。$A$$a$$B$$b$

重大な状態が存在します。 証明。上記から、多価状態で開始することがわかります。してみましょう全く動きをしません。AまたはBのいずれかがツリーを強制的に一価状態にしない限り、移動させます。待機フリー性は、ツリーが有限であることを保証するため、ある時点でクリティカルな状態に遭遇する必要があります。$C$$A$$B$$\square$

次に、クリティカル状態にあるシナリオを考えます。少なくとも 2つの可能性があります。

1）が動き（これによりaを決定）、停止します。その後、Bは移動して停止します。次のCは終了するまで実行され、最終的にaを決定します。$A$$a$$B$$C$$a$

2）が移動し（これによりbが決定されます）、停止します。次のCは終了するまで実行され、最終的にbを決定します。Aは動きません。$B$$b$$C$$b$$A$

アトミックな読み取りと書き込みはコンセンサス番号1を持っているため、とBの移動は同じレジスターでテストと設定の命令である必要がありました（レジスターが異なる場合、CはAとAの順序を認識できませんBの動きが起こった）。Cの視点、そして、シナリオ1と2は見分けがつかないので、我々はそれを持っている必要がありますCの両方を決定し、AとBを。不可能だよ。$A$$B$$C$$A$$B$$C$$C$$a$$b$$\square$

テストセット命令にはコンセンサス番号2があるということは、クレーム1と2の両方からわかります。

ウィキペディアの記事には質問に答えるリファレンスがありますが、おそらく26ページの論文は読みたくないでしょう。（非常に技術的な）証明の簡略版を提供し、テストとセットが3つのプロセスのバイナリコンセンサスを解決できないことを示します。この種の議論は、コンセンサス番号の証明に広く使用されています。

3つのプロセスにTASレジスタを使用するコンセンサスアルゴリズムがあるとします。

どの時点でも、各プロセスには実行の準備ができた移動（命令）があります。3つの命令のどれが実行されるかは非決定的です。

二価状態（0または1の両方の決定がまだ可能な状態）にあり、どちらのプロセスが次に移動する場合でも、後続の状態は一価になります。このような状態は、待機なしの状態のために最終的に到達する必要があります。

（wlg）プロセス1が移動すると状態が0価になり、プロセス2が移動すると状態が1価になると仮定します。両方の移動は、同じレジスターに対するTAS操作（または少なくとも何らかの書き込み）でなければなりません。異なるレジスターに対するTAS操作である場合、プロセス1が最初に移動したのかプロセス2が最初に移動したのかわかりません。

これら2つの可能な実行を考えてみましょう。

• プロセス1が最初に移動し、次にプロセス2が移動し、次にプロセス3が単独で実行されます
• プロセス2が最初に移動し、次にプロセス3が単独で実行されます

プロセス3の観点から見ると、これらの状態はプロセス2によって書き込まれた値を見るだけなので区別できません。ただし、最初の場合は出力として0を、2番目の場合は出力として1を与える必要があります。明らかに、これは矛盾です。

プロセス1と2は、最初に移動したものを自分自身で決定できます（書き込み前にレジスタの値を確認できるため）が、3番目の観客プロセスはできません。

テストとセットを使用して3プロセッサのコンセンサスを解決できないことを証明する別の方法は、テストとセットを2プロセッサのコンセンサスを使用して実装できることを示すことです。次に、テストとセットが3プロセッサのコンセンサスを解決できると仮定すると、矛盾が生じます。テストとセットが3プロセッサのコンセンサスを解決できると仮定します。その後、テストとセットを2プロセッサコンセンサスを使用した実装で置き換えることにより、2プロセッサコンセンサスを使用した3プロセッサコンセンサスの実装が得られますが、これは不可能です。したがって、テストセットは3プロセッサのコンセンサスを解決できません。

2プロセッサコンセンサスを使用してnプロセッサのテストアンドセットを実装するには、2プロセッサコンセンサスを使用して各マッチが実装されるトーナメントを使用して、プロセッサにテストアンドセットの勝者を決定させます（マッチでは、プロセッサ識別子を提案し、コンセンサスの結果が勝者を知らせます）。

実際的な意味では、それほど厳密ではないコンセンサス定義で十分かもしれません（ここでは、私はそれを軽いコンセンサスと呼びます）：

定義。（a）各スレッドが同じ値を決定するか、値が不明である場合、（b）少なくとも1つのスレッドが値を知っている場合、および（c）この値が実際に提案された場合スレッド。

したがって、より軽い意味でのこのコンセンサスは、一部のスレッドがコンセンサス、つまり決定された値を知らないことを可能にします。

結果：このより軽い意味では、テストとセットには無限の光コンセンサス数があります。

主張：この軽い感覚は実用的です。たとえば、クリティカルセクションに入るスレッドを選択するために、厳密な意味でコンセンサスを作成する必要はありません。つまり、各スレッドは選択されたかどうかを知る必要がありますが、選択されていない場合は、どのスレッドが選択されたかを知る必要はありません。つまり、相互排除の厳密な合意は必要ないため、光で十分です。