Thread safety object - static or not?

Question

I was recently in an interview and the tech guy asked me about how to make an application thread-safe.

Well, after explaining the lock() correctly, he s

Answer 1

He claimed the reason is that static is run at runtime instead of compilation and would make that object slower for threads to lock than if it was non static.

This doesn't really make any sense - I think either the interviewer did not know what he was talking about, or maybe you misunderstood his point.

Answer 2

If a lock object should be static or not depends on the object you want to lock. If you want to lock an instance of a class you cannot use a static lock object. If you want to lock static data you cannot use an instance lock object. So there seems not to be any choice.

You could think about using a static or an instance lock object to lock the access to instance data, but this results in different behaviors. With an instance lock object you lock only an instance while an static lock object will lock all instances. So no choice for performance tuning here, too.

Answer 3

Sometimes in job interviews I say something I know is incorrect or something that is utter nonsense to see if the candidate will effectively argue his point or just give up and agree.

Oh and here's an excellent article by Jeffrey Richter on the proper uses of lock. :)

Answer 4

The others are correct that the choice of using a static of instance field depends on what state (class-level or instance-level) that you need to lock, and there is no relevant difference in speed for the lock itself. BUT if you really only need to use instance data then your app could run much faster using lock(this) rather than locking out all threads from accessing the data of ANY instance. That might have been what the interviewer was getting at - in an application where multiple threads are only using instance data it should indeed run faster if you only lock the instance because it won't block other threads from using other instances.

Conversely if threads are accessing class-level (static) state then you need to lock them all with a single object. When I need to do this, a pattern I've used is to lock the type of the class like this:

[Edit - not such a good idea after all, see comments below]

lock(typeof(MyClass))
{
  // use class-level data
}

This avoids the necessity of creating the static object field.

Answer 5

Use a non static object for the lock whenever you need to make sure the same instance isn't manipulated by different threads at the same time.

Lets say you have some List classes, with a special Reorder method that accepts some strange arguments. Consider if you need to reorder 100 different lists during some paralel processes. You only care that different threads don't manipulate the same list at the same time, as it might affect your reorder logic. You don't need a static lock, as you don't care when different lists are being manipulated at the same time.

A simple example of a scenario with a static lock, is initialization of some static data, where you want to make sure the load logic is ran only once. Like some Cache or a Singleton.

Answer 6

If you have only one instance of a class that shares between multiple threads, it's ok to use normal object. but if you have multiple objects of a class that share between multiple threads, you have to use static object.

On the other hand, with normal object you can manage concurrency for one instance of a class and with static object you can manage concurrency in the scope of all instances of a class.