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.
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.Replaceetc 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.