ロックはどのように正確に機能しますか？

スレッドセーフではないオブジェクトを使用する場合、次のようなロックでコードをラップすることがわかります。

private static readonly Object obj = new Object();

lock (obj)
{
    // thread unsafe code
}

したがって、複数のスレッドが同じコードにアクセスするとどうなりますか（ASP.NET Webアプリケーションで実行されていると仮定しましょう）。彼らはキューに入っていますか？もしそうなら、彼らはどれくらい待つでしょうか？

ロックを使用することによるパフォーマンスへの影響は何ですか？

lock文は以下にC＃3.0で翻訳されています：

var temp = obj;

Monitor.Enter(temp);

try
{
    // body
}
finally
{
    Monitor.Exit(temp);
}

C＃4.0ではこれが変更され、次のように生成されます。

bool lockWasTaken = false;
var temp = obj;
try
{
    Monitor.Enter(temp, ref lockWasTaken);
    // body
}
finally
{
    if (lockWasTaken)
    {
        Monitor.Exit(temp); 
    }
}

ここで何Monitor.Enterが行われるかについての詳細情報を見つけることができます。MSDNを引用するには：

Enterパラメータとして渡されたオブジェクトのモニターを取得するために使用します。別のスレッドがEnter オブジェクトに対してを実行したが、対応するをまだ実行していないExit場合、現在のスレッドは、他のスレッドがオブジェクトを解放するまでブロックします。同じスレッドがEnterブロックせずに複数回呼び出すことは正当です 。ただし、Exitオブジェクトを待機している他のスレッドのブロックが解除される前に、同数の 呼び出しを呼び出す必要があります。

Monitor.Enter方法は無限に待機します。それはなりませんタイムアウト。

思ったより簡単です。

Microsoftによれば、このlockキーワードは、あるスレッドがコードのクリティカルセクションに入らず、別のスレッドがクリティカルセクションに入っていることを保証します。別のスレッドがロックされたコードを入力しようとすると、オブジェクトが解放されるまで待機、ブロックされます。

lockキーワードのコールEnterブロックの開始時とExitブロックの終わりに。lockキーワードは実際にはMonitorクラスをバックエンドで処理します。

例えば：

private static readonly Object obj = new Object();

lock (obj)
{
    // critical section
}

上記のコードでは、スレッドは最初にクリティカルセクションに入り、次にロックしますobj。別のスレッドが開始しようとするとobj、最初のスレッドによって既にロックされているもロックしようとします。2番目のスレッドは、最初のスレッドが解放されるのを待つ必要がありますobj。最初のスレッドが終了すると、別のスレッドがロックobjされ、クリティカルセクションに入ります。

いいえ、彼らはキューに入っていません、彼らは寝ています

次の形式のロックステートメント

lock (x) ... 

ここで、xは参照型の式であり、正確に以下と同等です。

var temp = x;
System.Threading.Monitor.Enter(temp); 
try { ... } 
finally { System.Threading.Monitor.Exit(temp); }

あなたは彼らがお互いに待っていることを知る必要があるだけで、1つのスレッドだけがブロックをロックするために入り、他のスレッドは待つでしょう...

モニターは.netで完全に記述されているので十分高速です。詳細については、リフレクター付きのクラスモニターも ご覧ください。

ロックは、他のスレッドがロックブロックに含まれるコードを実行するのをブロックします。スレッドは、ロックブロック内のスレッドが完了してロックが解放されるまで待機する必要があります。これは、マルチスレッド環境でのパフォーマンスに悪影響を及ぼします。これを行う必要がある場合は、ロックブロック内のコードが非常に迅速に処理できることを確認する必要があります。データベースへのアクセスなどの高額な作業は避けてください。

パフォーマンスへの影響は、ロックする方法によって異なります。ここで最適化の良いリストを見つけることができます：http : //www.thinkingparallel.com/2007/07/31/10-ways-to-reduce-lock-contention-in-threaded-programs/

待機中のコードがスリープ状態になるため、基本的にロックはできるだけ少なくする必要があります。重い計算や、長時間続くコード（ファイルのアップロードなど）がロックされていると、パフォーマンスが大幅に低下します。

ロックステートメント内の部分は1つのスレッドでのみ実行できるため、他のすべてのスレッドは、ロックを保持しているスレッドが終了するまで無期限に待機します。これにより、いわゆるデッドロックが発生する可能性があります。

lock文はへの呼び出しに変換されるEnterとExitする方法Monitor。

lockロックオブジェクトが解放されるのステートメントは、無期限に待機します。

ロックは実際には非表示のMonitorクラスです。