Thread Synchronization Construct Summary in C#

Maker PDF 417 in C# Thread Synchronization Construct Summary

My recommendation always is to avoid writing code that blocks any threads . When performing asynchronous compute or I/O operations, hand the data off from thread to thread in such a way to avoid the chance that multiple threads could access the data simultaneously . I demonstrated this with the pipe server and client code shown in 27, I/O-Bound Asynchronous Operations . If you are unable to fully accomplish this, then try to use the VolatileRead, VolatileWrite, and Interlocked methods because they are fast and they also never block a thread . Unfortunately, these methods manipulate only simple types, but you can perform rich operations on these types as described in the The Interlocked Anything Pattern section . There are two main reasons why you would consider blocking threads:

The programming model is simplified . By blocking a thread, you are sacrificing some resources and performance so that you can write your application code sequentially without using callback methods . A thread has a dedicated purpose . Some threads must be used for specific tasks . The best example is an application s primary thread . If an application s primary thread doesn t block, then it will eventually return and the whole process will terminate . Another example is an application s GUI thread or threads . Windows requires that a

window or control always be manipulated by the thread that created it, so we sometimes write code that blocks a GUI thread until some other operation is done and then the GUI thread updates any windows and controls as needed . Of course, blocking the GUI thread hangs the application and provides a bad end-user experience . To avoid blocking threads, don t mentally assign a label to your threads . For example, don t create a spell-checking thread, a grammar-checking thread, a thread that handles this particular client request, and so on . The moment you assign a label to a thread, you have also said to yourself that that thread can t do anything else . But threads are too expensive a resource to have them dedicated to a particular purpose . Instead, you should use the thread pool to rent threads for short periods of time . So a thread pool thread starts out spell checking, then it changes to grammar checking, and then it changes again to perform work on behalf of a client request, and so on . If, in spite of this discussion, you decide to block threads, then use the kernel object constructs if you want to synchronize threads that are running in different AppDomains or processes . To atomically manipulate state via a set of operations, use the Monitor class with a private field .6 Alternatively, you could use a reader-writer lock instead of Monitor . Reader-writer locks are generally slower than Monitor, but they allow multiple reader threads to execute concurrently, which improves overall performance and minimizes the chance of blocking threads . In addition, avoid using recursive locks (especially recursive reader-writer locks) because they hurt performance . However, Monitor is recursive and its performance is very good .7 Also, avoid releasing a lock in a finally block because entering and leaving exception-handling blocks incurs a performance hit, and if an exception is thrown while mutating state, then the state is corrupted and other threads that manipulate it will experience unpredictable behavior and security bugs . Of course, if you do write code that holds a lock, your code should not hold the lock for a long time because this increases the likelihood of threads blocking . In the Using Collections to Avoid Holding a Lock for a Long Time section, I will show a technique that uses collection classes as a way to avoid holding a lock for a long time . Finally, for compute-bound work, you can use tasks (discussed in 26) to avoid a lot of the thread synchronization constructs . In particular, I love that each task can have one or more continue-with tasks associated with it that execute via some thread pool thread when some operation completes . This is much better than having a thread block waiting for some operation to complete . For I/O-bound work, the Asynchronous Programming Model (APM) invokes your callback method when the I/O operation completes; this is similar to a task s continue-with task .

You could use a SpinLock instead of Monitor because SpinLocks are slightly faster . But a SpinLock is potentially dangerous because it can waste CPU time and, in my opinion, it is not sufficiently faster than Monitor to justify its use . This is partially because Monitor is actually implemented in native code, not managed code .