ロックステートメントはどれくらい高価ですか？

私はマルチスレッドと並列処理を実験しており、基本的なカウントと処理速度の統計分析を行うためのカウンターが必要でした。クラスの同時使用に関する問題を回避するために、クラスのプライベート変数にロックステートメントを使用しました。

private object mutex = new object();

public void Count(int amount)
{
 lock(mutex)
 {
  done += amount;
 }
}

しかし、私は不思議に思っていました...変数のロックはどれほど高価ですか パフォーマンスへの悪影響は何ですか？

こちらがコストになる記事です。短い答えは50nsです。

技術的な答えは、これを定量化することは不可能であり、CPUメモリのライトバックバッファーの状態と、プリフェッチャーが収集して破棄して再度読み取る必要のあるデータの量に大きく依存します。どちらも非常に非決定的です。大きな失望を回避するために、150のCPUサイクルをエンベロープの逆近似として使用しています。

実際の答えは、ロックをスキップできると思うときにコードのデバッグに費やす時間よりもずっと安いということです。

正確な数値を取得するには、測定する必要があります。Visual Studioには、拡張機能として使用できる洗練された同時実行アナライザーがあります。

参考文献：

一般的な同期プリミティブに関心があり、異なるシナリオとスレッド数に応じて、モニター、C＃ロックステートメントの動作、プロパティ、コストを掘り下げている記事をいくつか紹介したいと思います。CPUの浪費とスループット期間に特に関心があり、複数のシナリオでどれだけの作業をプッシュできるかを理解します。

https://www.codeproject.com/Articles/1236238/Unified-Concurrency-I-Introduction https://www.codeproject.com/Articles/1237518/Unified-Concurrency-II-benchmarking-methodologies https：// www。 codeproject.com/Articles/1242156/Unified-Concurrency-III-cross-benchmarking

元の答え：

まあ！

THE ANSWERは本質的に正しくないため、ここでフラグが付けられた正解のようです！回答の著者には、リンク先の記事を最後まで読んでいただきますようお願いいたします。論文

2003年の記事の著者は、Dual Coreマシンのみで測定しており、最初の測定ケースではシングルスレッドのみでロックを測定し、結果としてロックアクセスあたり約50nsでした。

並行環境でのロックについては何も言われていません。したがって、記事を読み続ける必要があり、後半では、2つおよび3つのスレッドを使用するロックシナリオを測定しました。これにより、今日のプロセッサの同時実行レベルに近づきます。

したがって、作者は、デュアルコアに2つのスレッドがある場合、ロックのコストは120ns、3つのスレッドがある場合は180nsになると述べています。そのため、同時にロックにアクセスするスレッドの数に明らかに依存しているようです。

したがって、それは単純です。ロックが役に立たなくなるシングルスレッドでない限り、50 nsではありません。

考慮すべきもう1つの問題は、平均時間として測定されることです。

反復時間が測定される場合、単純に大部分が高速であったために1ミリ秒から20ミリ秒の間の時間さえありますが、プロセッサ時間を待っているスレッドはほとんどなく、ミリ秒も長い遅延が発生します。

これは、高スループット、低遅延を必要とするあらゆる種類のアプリケーションにとって悪いニュースです。

そして最後に考慮すべき問題は、ロック内の処理が遅くなる可能性があることです。これは、多くの場合そうです。コードのブロックがロック内で実行される時間が長いほど、競合が高くなり、遅延が非常に高くなります。

2003年からすでに10年以上が経過していることを考慮してください。これは、完全に同時に実行するように特別に設計された数世代のプロセッサであり、ロックによってパフォーマンスが大幅に低下しています。

これはパフォーマンスに関するクエリには答えませんが、.NET Frameworkは、別のオブジェクトを手動でロックしなくてもメンバーにInterlocked.Addを追加できるメソッドを提供していると言えるでしょう。amountdone

lock （Monitor.Enter / Exit）は非常に安価で、WaithandleやMutexなどの代替手段よりも安価です。

しかし、それが（少し）遅い場合は、間違った結果を伴う高速なプログラムを作成したいと思いませんか？

タイトなループでのロックのコストは、ロックなしの代替と比較して莫大です。何度もループする余裕があっても、ロックよりも効率的です。そのため、ロックフリーキューは非常に効率的です。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace LockPerformanceConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = new Stopwatch();
            const int LoopCount = (int) (100 * 1e6);
            int counter = 0;

            for (int repetition = 0; repetition < 5; repetition++)
            {
                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    lock (stopwatch)
                        counter = i;
                stopwatch.Stop();
                Console.WriteLine("With lock: {0}", stopwatch.ElapsedMilliseconds);

                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    counter = i;
                stopwatch.Stop();
                Console.WriteLine("Without lock: {0}", stopwatch.ElapsedMilliseconds);
            }

            Console.ReadKey();
        }
    }
}

出力：

With lock: 2013
Without lock: 211
With lock: 2002
Without lock: 210
With lock: 1989
Without lock: 210
With lock: 1987
Without lock: 207
With lock: 1988
Without lock: 208

「コスト」を定義する方法はいくつかあります。ロックの取得と解放には実際のオーバーヘッドがあります。ジェイクが書いているように、この操作が何百万回も実行されない限り、それは無視できます。

より適切なのは、これが実行のフローに及ぼす影響です。このコードは、一度に1つのスレッドしか入力できません。この操作を定期的に実行するスレッドが5つある場合、そのうち4つはロックが解放されるのを待ち、そのロックが解放された後、そのコードに入る予定の最初のスレッドになります。したがって、アルゴリズムは大幅に影響を受けます。その程度は、アルゴリズムと操作が呼び出される頻度に依存します。競合状態を導入せずにそれを回避することはできませんが、ロックされたコードへの呼び出しの数を最小限に抑えることで改善できます。