Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This could be a <em>massive</em> list - read Joe Duffy's excellent "<a href="http://rads.stackoverflow.com/amzn/click/032143482X" rel="noreferrer">Concurrent Programming On Windows</a>" for much more detail. This is pretty much a brain dump...</p> <ul> <li>Try to avoid calling into significant chunks of code while you own a lock</li> <li>Avoid locking on references which code outside the class might also lock on</li> <li>If you ever need to acquire more than one lock at a time, always acquire those locks in the same order</li> <li>Where reasonable, use immutable types - they can be shared freely between threads</li> <li>Other than immutable types, try to avoid the need to share data between threads</li> <li>Avoid trying to make your types threadsafe; most types don't need to be, and usually the code which needs to share data will need to control the locking itself</li> <li>In a WinForms app: <ul> <li>Don't perform any long-running or blocking operations on the UI thread</li> <li>Don't touch the UI from any thread other than the UI thread. (Use BackgroundWorker, Control.Invoke/BeginInvoke)</li> </ul></li> <li>Avoid thread-local variables (aka thread-statics) where possible - they can lead to unexpected behaviour, particularly on ASP.NET where a request may be served by different threads (search for "thread agility" and ASP.NET)</li> <li>Don't try to be clever. Lock-free concurrent code is <em>hugely</em> difficult to get right.</li> <li>Document the threading model (and thread safety) of your types</li> <li>Monitor.Wait should almost always be used in conjunction with some sort of check, in a while loop (i.e. while (I can't proceed) Monitor.Wait(monitor))</li> <li>Consider the difference between Monitor.Pulse and Monitor.PulseAll carefully every time you use one of them.</li> <li>Inserting Thread.Sleep to make a problem go away is never a real fix.</li> <li>Have a look at "Parallel Extensions" and the "Coordination and Concurrency Runtime" as ways of making concurrency simpler. Parallel Extensions is going to be part of .NET 4.0.</li> </ul> <p>In terms of debugging, I don't have very much advice. Using Thread.Sleep to boost the chances of seeing race conditions and deadlocks can work, but you've got to have quite a reasonable understanding of what's wrong before you know where to put it. Logging is very handy, but don't forget that the code goes into a sort of quantum state - observing it via logging is almost bound to change its behaviour!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload