Lock's purpose is clear: just don't want someone else to use this code, in the case of multithreading, only allow the current thread to execute the code area, other threads wait until the thread execution ends, so that multithreading avoids the simultaneous use of a method to cause data confusion.
The general definition is as follows:
private static readonly Object obj = new Object ();
Lock (obj)
{
"' Code block
}
MSDN gives: Our lock is generally an object, not a numeric value and a string.
1. Why can't lock value type
Like lock (1)? Lock essentially monitor.enter,monitor.enter the value type, each time the lock is a boxed object. Lock is actually a compiler-like syntax sugar, so the compiler directly restricts the lock value type. Step back 10,000 to say, even if the compiler allows you to lock (1), but object. ReferenceEquals always returns False (since each boxing is a different object), that is, each time it is judged not to request a mutex, so that at the same time, other threads can still access the inside of the code, does not achieve the effect of synchronization. Likewise, lock (object) 1 is not.
2. Lock string
What about the lock ("xxx") string? The exact words on MSDN are:
Locking a string is especially risky because the string is persisted by the common language runtime (CLR). This means that there is only one instance of any given string in the entire program, and the same object represents that text in all the threads of all running application domains. Therefore, whenever a lock is placed on a string that has the same content anywhere in the application process, all instances of that string in the application are locked.
3. MSDN Recommended Lock Object
In general, it is a good idea to avoid locking public types or locking object instances that are not under application control. For example, if the instance can be publicly accessible, lock (this) may be problematic because uncontrolled code may also lock the object. This can result in a deadlock, where two or more threads wait to release the same object. For the same reason, locking public data types (compared to objects) can also cause problems.
and lock (this) is only valid for the current object, if the synchronization effect is not achieved between multiple objects.
The custom class recommends using private read-only static objects, such as:
private static readonly Object obj = new Object ();
Why should it be set to read-only? This is because if you change the value of obj in the lock code snippet, the other threads are unblocked because the mutex object has changed. ReferenceEquals must return FALSE.
C # Lock Usage