Rules for finding / avoiding shared data in a multithreaded application

Question

Hy,

as we all know, developing a multithreading application is a hard thing. Especially the point when and what to lock is not so obvious IMHO. Often I'm looking at a method / class and I must ask myself, if I share some data, which can be modified by multiple threads. And when I'm not sure it ends in a lock( ) over a whole code block.

So what I like to know: Do you have suggestions for patterns / rules etc. to identify shared data? Or techniques to ensure that your code is thread-safe.

E.g.:

• Static methods shouldn't modify class fields. (Unless they lock the field.)
  
• Reference type'd parameters of a method should not be passed "directly". Always pass a clone.

By the way:

Microsoft Research is working on CHESS. A tool for finding and reproducing Heisenbugs in concurrent programs. I hope this and PLINQ will make improve development of concurrent programs.

Answer 1

Wherever possible, make your types immutable to start with. Then there's no need to clone. If you need to "change" the contents of an object, make the method return a new object instead - just like String.Replace etc does.

This is basically the functional programming style, and it's lovely. It's unfortunate that we don't (currently) have immutable collections built into the .NET framework, althoughthere are third party ones around, including one by our own JaredPar.

Answer 2

Encapsulating data in a class is useful when making it thread safe. You get control over how the data is accessed, and you can make the class responsible for the synchronising instead of having code all over the application trying to synchronise properly.

Also, you have somewhere to put a private variable that you can use as lock identifier, so that you can avoid using the data itself as identifier for the lock. By having a private variable dedicated as lock identifier you remove one possible source of deadlocks.