C # multi-thread programming: Considerations for using lock

1. avoid locking public objects.

If the instance can be accessed by the public, the lock (this) problem occurs.

If there is a class myclass, this class has a method that uses lock (this) to achieve mutual exclusion:

 1   Public  Class myclass
  2   {
  3     Public     Void  Method ()
  4  {
  5     Lock  (  This  )
  6   {
  7   ......
  8   }
  9   }
  10   } 

If a myclass instance executes the method in different threads, mutual exclusion can be implemented. However, if multiple myclass instances execute the method in different threads, the mutex will fail because the lock (this) here only locks the current instance object.

2. Disable lock type

Lock (typeof (classname) has a wider range of locks, because all instances of a class have only one type object (this object is the return result of typeof), lock it, all instances of the object are locked. Microsoft now suggested (for the original article, refer to: http://www.microsoft.com/china/MSDN/library/enterprisedevelopment/softwaredev/SDaskgui06032003.mspx? MFR = true) do not use lock (typeof (classname )). The original Microsoft text description is as follows:

First, locking type objects is a very slow process, and other threads in the class, even in the same applicationProgramOther programs running in the domain can access this type of object. Therefore, they may block your execution instead of locking the type object, resulting in your ownCode.

The basic problem here is that you do not own this type of object, and you do not know who else can access it. In general, relying on locking is not a bad practice for you to create and you do not know who else can access objects. This can easily lead to deadlocks.

3. Do not lock strings

Locking a string is even more amazing. As long as the string content is the same, it can cause the program to be suspended.

In. net, strings are temporarily stored. If the two variables have the same string content,. NET will allocate the temporary String object to the variable. So if both of them are using lock ("My lock"), they actually lock the same object.

How can I use lock correctly?

Microsoft provides the following suggestions:Only private objects are locked.

Sample Code:

 1   Public  Class myclass
  2   {
  3    Private     Static  Object someprivatestaticobject  =     New  Object ();
  4   
  5     //  Methods of class go here -- can lock someprivatestaticobject  
 6       Public     Void  Method ()
  7   {
  8     Lock  (Someprivatestaticobject)
  9   {
  10   ......
 11   }
  12   }
  13   } 

Benefits of locking private objects:

First, no code except the class can lock myclass. someprivatestaticobject, thus avoiding many deadlocks. Since deadlocks are the most difficult problem to find the root cause, it may be a good thing to avoid deadlocks.

Second, there is only one copy of myclass. someprivatestaticobject in the application, and each other application running on the system has only one copy. Therefore, applications in the same application domain do not affect each other.