lock keyword in C #

A few days ago and colleagues heated discussion, a little harvest, recorded.

First, give the definition of MSDN:

The lock keyword can be used to ensure that a block of code finishes running without being interrupted by another thread. This is accomplished by acquiring a mutex for a given object while the code block is running.

Let's take a look at the execution process, and the code example is as follows:

If thread a executes first, thread B is slightly slower. Thread A executes to the lock statement to determine if obj has applied for a mutex and is based on the object of an existing lock. ReferenceEquals comparison (not confirmed here), if it does not exist, apply for a new mutex, when thread a enters lock.

This assumes that thread B is started, and thread A has not finished executing the code in lock. Thread B executes to the lock statement, checks that obj has requested a mutex, waits until thread a completes, releases the mutex, and thread B can request a new mutex and execute the code inside the lock.

Next, let's say something about the lock.

Why not lock value types, such as lock (1)? Lock essentially monitor.enter,monitor.enter the value type, each lock is a boxed object. Lock is actually similar to compiler syntax sugar, so the compiler directly restricts the lock value type. 10,000 step back, even if the compiler allows you to lock (1), but object. ReferenceEquals (1,1) always returns False (since each boxing is a different object), that is, each time it is judged not to apply for mutexes, so that at the same time, other threads can access the inside of the code, do not achieve the effect of synchronization. Nor is the same lock (object 1).

What about the lock ("xxx") string? The exact words on MSDN are:

Locking a string is particularly dangerous because the string is "temporarily" reserved by the common language runtime (CLR). This means that there is only one instance of any given string in the entire program, that is, the same object represents the text in all threads of all running application domains. Therefore, whenever a lock is placed on a string with the same content anywhere in the application process, all instances of that string in the application are locked. In general, it is best to avoid locking public types or locking object instances that are not controlled by the application. For example, if the instance can be publicly accessed, lock (this) may be problematic because uncontrolled code may also lock the object. This can result in a deadlock in which two or more threads wait to release the same object. For the same reason, locking a common data type (compared to an object) can also cause problems. and lock (this) is only valid for the current object, if the effect of synchronization is not reached between multiple objects.

Lock (typeof (Class)) is as wide as a locked string. Some system classes provide members that are dedicated to locking. For example, the Array type provides SyncRoot. Many collection types also provide SyncRoot. The custom class recommends a private read-only static object, such as: private static readonly Object obj = new Object (); Why do you want to set it to read-only? This is because if you change the value of obj in the lock snippet, the other threads will be free, because the objects of the mutex are changed, object. ReferenceEquals must return FALSE.