CompareExchangeに基づくインターロックされた実装はSpinWaitを使用する必要がありますか？

以下は、に基づくインターロックされたメソッドの実装ですInterlocked.CompareExchange。

このコードでSpinWait繰り返しを行う前にスピンを使用することをお勧めしますか？

public static bool AddIfLessThan(ref int location, int value, int comparison)
{
    int currentValue;
    do
    {
        currentValue = location; // Read the current value
        if (currentValue >= comparison) return false; // If "less than comparison" is NOT satisfied, return false
    }
    // Set to currentValue+value, iff still on currentValue; reiterate if not assigned
    while (Interlocked.CompareExchange(ref location, currentValue + value, currentValue) != currentValue);
    return true; // Assigned, so return true
}

私はSpinWaitこのシナリオで使用されているのを見てきましたが、私の理論では、それは不必要なはずです。結局のところ、ループには少数の命令しか含まれておらず、常に1つのスレッドが進行しています。

このメソッドを実行するために2つのスレッドが競合していて、最初のスレッドはすぐに成功するが、2番目のスレッドは最初は何も変更を行わず、繰り返す必要があるとします。他の候補がない場合、2番目のスレッドが2回目の試行で失敗することはまったく可能ですか？

例の2番目のスレッドが2回目の試行で失敗しない場合、SpinWait？で何が得られるでしょうか。メソッドを実行するために100のスレッドが競合しているというまれなイベントで、数サイクルを削ぎ落としますか？

私の専門家ではない意見では、この特定のケースでは、2つのスレッドが時々を呼び出すためAddIfLessThan、a SpinWaitは不要です。2つのスレッドが両方ともAddIfLessThanタイトなループで呼び出している場合は、各スレッドが中断せずに数マイクロ秒間進行できるようにすると便利です。

実際に私は実験を行い、AddIfLessThanタイトなループで呼び出す1つのスレッドと2つのスレッドのパフォーマンスを測定しました。同じ数のループを（累積的に）作成するには、2つのスレッドで約4倍の時間が必要です。SpinWaitミックスにa を追加すると、2つのスレッドは単一のスレッドよりもわずかに遅くなります。

2つのスレッドについては、SpinWait議論の対象にはなりません。しかし、このコードは、リソースを実際に争うことができるスレッドの数を知らせず、比較的多くのスレッドを使用するSpinWaitことで、有益になる可能性があります。特に、スレッドの数が多いと、リソースを正常に取得しようとしているスレッドの仮想キューが長くなり、たまたま最終的にサービスが提供されるこれらのスレッドは、スケジューラによって割り当てられたタイムスライスを超える可能性が高くなり、より高いCPU消費につながり、優先度が高くても、他のスケジュールされたスレッドの実行に影響を与える可能性があります。のSpinWait許可されたスピンの上限を設定することにより、この状況に適切な回答が得られます。その後、コンテキストの切り替えが実行されます。したがって、コンテキストの切り替えをトリガーするために高価なシステムコールを行う必要性と、特定の状況で他のスレッドの実行に影響を与えるリスクのある制御されていないユーザーモードのCPU消費との間の妥当なトレードオフです。