17.4 Threading guidelines

Use threads only when there is a real need for multi-threading , such as if you have multiple CPUs and are writing a computation intensive application which has a user interface portion. While one thread deals with user interaction, the other can be performing background computation concurrently.

Avoid using multiple threads unnecessarily because not only does writing such applications require a higher level of expertise, it is also often difficult to debug threaded applications. ^[20]

^[20] This is true especially for bugs due to inconsistent state which resulted from thread synchronization problems. The difficulty is exacerbated by the fact that multi-threaded applications always give different outputs depending on various factors decided on by the operating system's scheduler and the current load on the CPU.

You have to keep in mind performance issues when writing multi-threaded applications “ dividing a task amongst many threads can help if you have more than one CPU, and if some of these threads can be kept waiting (for example, threads awaiting user input). However, having too many critical section code blocks ^[21] or having too many mutex objects that require waiting on may slow things down considerably. A good rule of the thumb is to have as few critical section code blocks as possible, and to enclose as few statements as possible into each.

^[21] 'Critical section code blocks' are code blocks which only one thread can execute at any one time. They are usually delimited by lock 's curly brace or Monitor.Enter() and Monitor.Exit() .

When searching for code to optimize, a good developer will pay special attention to how a multi-threaded application is written, and the justification for placing codes in critical sections.