What is difference between lock(private instance) and lock(private static instance)?

[nytimescnn]

I've read some discuession about lock() for thread-safe. I am wondering
what will be the differce between below two code segment?

Code 1:

class A
{
private static Object padlock = new Object();

...// some codes

public static Method()
{
lock(padlock)
{
...// some codes

}
}
}

Code 2:
class A
{

...// some codes

public static Method()
{
private Object padlock = new Object(); //HERE it is NOT static
variable
lock(padlock)
{
...// some codes

}
}
}

My understanding is only Code1 works fine, since it will lock on a
common static variable for all threads. Code2 will NOT work since each
time it will create a private instance, and lock will be on different
(new created) instance each time. Am I correct?

Thanks,

 

[Nicholas Paldino [.NET/C# MVP]]

Yes, you are correct sir!

 

[Brian Gideon]

I assume that in code 2 you meant to place padLock outside of Method.
When synchronizing static methods you usually use a static lock object
and when using instance methods you usually use an instance lock
object. It really depends on what you're accessing inside the lock
block. For example, if you have an instance method that accesses a
static resource then you may want to lock using a static object
instead. But, yes, in general your understanding is correct. Just
don't apply it to every scenario though. Consider what it is that
you're trying to synchronize first.

Brian

 

[nytimescnn]

Thanks for your reply. In fact what we have is trying to access a
public shared Resource from a static method of class. I think we should
use private static variable to lock.
For another case, as you said. "......when using instance methods you
usually use an instance lock object....", so is code example below
correct?

class A
{

private static sharedResource sr;
private Object padlock = new Object();

public void MethodToAccessStaticResource()
{
lock(padlock)
{
...// some codes to access sharedResources..

}
}
}

Thanks,

 

[Brian Gideon]

In general I would say no. The code is probably not thread-safe. The
reason is because you're accessing a static object from within a lock
that uses an instance object. What what might happen is that two or
more separate instances of class A may execute
MethodToAccessStaticResource and all will acquire the lock (since it
was based on an instance object) and all may simultaneously access the
single sharedResource object. Now, if sharedResource itself is
thread-safe then it might be okay, but that's not necessarily the case.
I'm not sure I'm explaining this very well so I apologize.

Brian

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


You are correct, padlock should be static too.

 

[CoolFish]

Thank you and I think your explanation is wonderful and clear. But in
which case do we create private NON-static instance as lock object and
use it as a parameter of the lock()? I really don't know if such
senario exists.. Or do you have an example to show the case?

Thanks,

 

[Brian Gideon]

Thank you and I think your explanation is wonderful and clear. But in
which case do we create private NON-static instance as lock object and
use it as a parameter of the lock()? I really don't know if such
senario exists.. Or do you have an example to show the case?

Thanks,

An instance object may be used for the lock anytime your code is only
accessing instance members.

public class Example
{
private Object lockObject = new Object();
private int foo = 5;

public void DoSomething()
{
lock (lockObject)
{
foo = foo + 5;
}
}
}

Brian

 

[CoolFish]

OK I got it this time.
I think one senario could be that we use the instance method as a
parameter passed to the ThreadStart() delegate.. then we will have the
case that instance method accesses instance memeber within different
thread, thus we need lock() on the instance object.

Thanks for all replys !