11

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 said it is not a good idea to have the object as static.

private static readonly object _syncLock = new object();

He claimed the reason is that static makes that object slower for threads to lock than if it was non static. Is this true?

EDIT: Nonetheless I am still not sure. What is the difference between these three approaches?

private static readonly object _syncLock = new object();
public static readonly object _syncLock = new object();
private readonly object _syncLock = new object();
ire_and_curses
  • 68,372
  • 23
  • 116
  • 141
Houman
  • 64,245
  • 87
  • 278
  • 460

6 Answers6

12

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.

Daniel Brückner
  • 59,031
  • 16
  • 99
  • 143
  • Your explanation makes very much sense, however don't forget its a private static. Nothing from outside could access it anyway. – Houman Apr 22 '09 at 23:16
  • This is what I thought also. Having the lock object as non-static would change the scope of the lock. – Brendan Kowitz Apr 23 '09 at 01:07
7

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.

matt b
  • 138,234
  • 66
  • 282
  • 345
  • i was thinking the exact same thing (and typing). – Darren Kopp Apr 22 '09 at 22:36
  • I have made notes. He said static would be slower in this case. I am not defending him I am trying to find the truth. :) – Houman Apr 22 '09 at 23:19
  • Then, the truth is he doesn't know what he's talking about! – matt b Apr 22 '09 at 23:41
  • Saying static is slower for this is one thing ... adding because "is run at runtime" is what makes it nonsense in this context – eglasius Apr 23 '09 at 09:09
  • Alright guys, questions has been clarified, can you read it again? – Houman Apr 23 '09 at 09:30
  • Still makes no sense on it's face. I don't believe there should be any difference in speed in accessing a shared member variable vs an instance variable. Perhaps he meant that you would cause unnecessary blocking using a static lock where a non-static lock would work? Meaning that the operations don't need to be synchronized across the class, just across instances of it... it's really hard to say for sure without knowing the exact context of the question / program. – matt b Apr 23 '09 at 12:38
  • @Matt, now forgetting the speed issue, what is the difference between private static readonly object _syncLock = new object(); private readonly object _syncLock = new object(); Dont forget, they are both private! What difference does it make? – Houman Apr 23 '09 at 12:55
  • The first is static, the second is not... if you are unsure of the difference between static and non-static, you probably should read up on that a bit – matt b Apr 23 '09 at 13:12
  • I know what the difference is. I just don't see the difference regarding the threading context. The threads cant access the sync object anyway from outside. So whats the point having it static or not? Thats what the interviewer said, and I think you couldn't have answered him either, when you were there. ;-) – Houman Apr 23 '09 at 21:47
0

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.

Mori
  • 2,484
  • 5
  • 28
  • 45
0

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. :)

JP Alioto
  • 44,864
  • 6
  • 88
  • 112
  • 1
    Aren't you worried that this will backfire? If I encountered a job interviewer who made some incorrect opinions, I might come away from the interview thinking that company was pretty poor from a technical standpoint – matt b Apr 22 '09 at 22:46
  • 1
    Nope, I have to know if a guy thinks he's right, he can effectively argue his point. Otherwise the other developers in my organization will eat him alive. – JP Alioto Apr 22 '09 at 23:13
  • 3
    Plus, I think it's better to see that your potential boss can be persuaded. There's nothing worse than a manager who cannot admit they are wrong. – JP Alioto Apr 22 '09 at 23:15
  • in all honesty, I would have a strong reservation against working in company that bullies you into accepting wrong paradigms straight on a job interview, I could only imagine what they will make you do once you start working for them. I would reasonably explain my point, and if interviewer starts pressing you into accepting his point of view without rational reasons - run away from this company – galets Apr 22 '09 at 23:31
  • 3
    I think JP is saying that he wants to see if the candidate attempts to correct the interviewer, how persuasive the candidate is, etc., or if the candidate lets it slide or (worse) doesn't even notice the BS. I don't see anything here about bullying – matt b Apr 22 '09 at 23:41
0

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.

eglasius
  • 35,831
  • 5
  • 65
  • 110
  • All you say is valid. However please explain me what the difference it makes if the object is private anyway. if its private no thread can access it from outside anyway. So whats the point of having a private static in this case? The private kills the meaning of static. – Houman Apr 23 '09 at 09:37
  • Not really, being private doesn't have any relation with static. In fact, given it is there just for the lock, it should be private. You want the locks to take place inside the implementation of the class, so there is no point in exposing that to the outside world. In the loading examples, you want the lock to be handled internally when you call a static property like: MyClass.Current. It is the implementation of Current that uses the lock to make sure it doesn't loads the instance twice. – eglasius Apr 23 '09 at 17:00
-1

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.

JayMcClellan
  • 1,601
  • 1
  • 11
  • 10
  • Nice idea to lock(typeof(MyClass)). +1 But you should not always use it for the same reason you should not just always use lock(this). You will lock the whole instance or all static data while you might only need to lock a small part of it. Creating dedicated lock objects allows you to have several locks per instance ot type and perform more granular locking. – Daniel Brückner Apr 23 '09 at 02:01
  • 1
    Sorry, I have to revoke my vote. Just learned how bad this code really is. See http://bytes.com/groups/net-c/249277-dont-lock-type-objects for details. – Daniel Brückner Apr 23 '09 at 02:13
  • 1
    It becomes even worse. lock(this) is an equally bad choice - see http://msdn.microsoft.com/de-de/magazine/cc188793(en-us).aspx for details. Lesson learned: Only lock on private instance or static objects of a reference type! – Daniel Brückner Apr 23 '09 at 02:21
  • I was just about to say, lock(this) is another interview question saying why this approach is a bad one. It could lead easily to deadlocks. nonetheless I am still not sure, what is the difference between private instance lock of an object against public static lock of an object vs. private static lock of an object. – Houman Apr 23 '09 at 07:56
  • Daniel, after reading that article I have to agree that locking the type object is a bad idea. And guess where I learned the technique - by using Reflector on Microsoft's own code! I wish I could remember where it was exactly but it was a long time ago. One can only hope it's been improved in the latest framework. – JayMcClellan Apr 24 '09 at 19:46