.NET Framework 2.0 Performance Inspection Questions - Locking and Synchronization

From Guidance Share

Jump to: navigation, search

- Web Application Performance Design Inspection Questions - Concurrency


Do You Use Mutex Objects?

Review your code and make sure that Mutex objects are used only for cross-process synchronization and not cross-thread synchronization in a single process. The Mutex object is significantly more expensive to use than a critical section with the Lock (C#) or SyncLock (VB) statement.

Do You Use the Synchronized Attribute?

See which of your methods are annotated with the synchronized attribute. This attribute is coarse-grained and it serializes access to the entire method such that only one thread can execute the method at any given instance, with all threads waiting in a queue. Unless you specifically need to synchronize an entire method, use an appropriate synchronization statement (such as a lock statement) to apply granular synchronization around the specific lines of code that need it. This helps to reduce contention and improve performance.

Do You Lock "this"?

Avoid locking "this" in your class for correctness reasons, not for any specific performance gain. To avoid this problem, provide a private object to lock on.

  public class A {
    …  lock(this) { … }
  // Change to the code below:
  public class A 
    private Object thisLock = new Object();
    …  lock(thisLock) { … }

Use this approach to safely synchronize only relevant lines of code. If you require atomic updates to a member variable, use System.Threading.Interlocked.

Do You Lock The Type of an Object?

Avoid locking the type of the object, as shown in the following code sample.


If there are other threads within the same process that lock on the type of the object, this might cause your code to hang until the thread locking the type of the object is finished executing.

This also creates a potential for deadlocks. For example, there might be some other application in a different application domain in the same process that acquires a lock on the same type and never releases it.

Consider providing a static object in your class instead, and use that as a means of synchronization.

  private static Object _lock = new Object();

For more information, see "A Special Dr. GUI: Don't Lock Type Objects!" on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaskdr/html/askgui06032003.asp.

Do You Use ReaderWriterLock?

Check whether your code uses ReaderWriterLock objects to synchronize multiple reads and occasional writes. You should prefer the ReaderWriterLock over the other locking mechanisms such as lock and Monitor, where you need to occasionally update data which is read frequently, such as a custom cache collection. The ReaderWriterLock allows multiple threads to read a resource concurrently but requires a thread to wait for an exclusive lock to write the resource.

For more information, see "ReaderWriterLock Class" in the .NET Framework Class Library on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemThreadingReaderWriterLockClassTopic.asp.

More Information For more information about the questions and issues raised in this section, see Explained: Locking and Synchronization Explained and .NET 2.0 Performance Guidelines - Locking and Synchronization.

To review your approach to locking and synchronization from a design perspective, see Web Application Performance Design Inspection Questions - Concurrency.

Personal tools