Locking Style for Concurrent Programs (c#)

As a job I do a lot of asynchronous programming. I have been working intensively with multi threading some 6 years now (before that I did programming on Unix in c++).

As a consequence of the problems I encountered during this 6 year period, the way I use locks has changed a lot. The most recurring problems were:

• deadlocks.
• pumping on the UI thread. When the UI-thread waits on a lock, the runtime can decide to start pumping on that call stack!!! This way *any* code can be called from nearly any point in your code. This can easily cause deadlocks or other (crazy) faulty programs because of unexpected reentry.
• performance: I used to take my locks over longer periods of time. For example during doing I/O or remoting to get some kind of serialization behavior. Instead it has shown to be a better idea to schedule work where possible, as it is often not important when something really happens.

I adopted a certain style when writing code with locks, in effect limiting the way in which locks are used. They are now used only to protect against concurrent access of fields and possibly to order the task scheduling. This style forces me to use other (higher level) constructs for coordination. This style has served me well in writing cleaner concurrent code.