I had the discussions with my friends on this Statics & Thread Safety issues long time ago. It started with a weird “session swap” issue in one of our web application where we use “static” field to store the return value for an user profile int the data access component. The problem is only captured in a stress test but not unit test. That so reminds me another interesting topic on testing method I'd like to talk about in a seperate post.
I see many developers new to C# repeating the mistake I made lately. I guess one reason is the misleading by MS's document itself. Many places in MSDN have the remark in the “Thread Safety” section: "Any public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe." I believe Microsoft says so is because they wrote the code in a thread safe manner.
The general idea is that static method is not a problem, but static variables where you store data. A local variable inside a method (even a static method) exists on the stack one for each thread. It's private to a thread of execution as long as it's not “static“. A static variable will be shared by all threads, that's problem! (Unless it's read only)
I found Scott Allen's article is the best so far in this topic. You can read it here:
http://odetocode.com/Articles/313.aspx
http://odetocode.com/Articles/314.aspx
Scott demonstrate the basic lock/Synchronization mechanisms in his article too. But be aware of dead-lock issue when you go that path. For more information, here is a guideline from MSDN I feel usefull:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconthreadingdesignguidelines.asp
I haven't tried to see how it behaves on a server farm configuration. I feel cross-server locking will be hard or too expensive to implement. I'm going to post it here once I got time. If you have such experience. please let me know.