what's wrong with lock(this) ?

[n_o_s_p_a__m]

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?

-KJ

[Frans Bouma [C# MVP]]

n_**********@mail.com (n_o_s_p_a__m) wrote in
news:1f**************************@posting.google.c om:

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?

lock() is most of the time used as a semaphore for a critical
action. To prevent multiple threads entering the same codeblock, an object
is locked (the parameter to lock()). THe bigger the object, the more time
it costs to lock it. So if you just want to prevent multiple threads
entering a codeblock, you'd better do this:

object uniqueObject = new object();

lock(uniqueObject)
{
// your code
}

Frans.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe******************@xs4all.nl> wrote:

n_**********@mail.com (n_o_s_p_a__m) wrote in
news:1f**************************@posting.google.c om:

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?

lock() is most of the time used as a semaphore for a critical
action. To prevent multiple threads entering the same codeblock, an object
is locked (the parameter to lock()). THe bigger the object, the more time
it costs to lock it. So if you just want to prevent multiple threads
entering a codeblock, you'd better do this:

object uniqueObject = new object();

lock(uniqueObject)
{
// your code
}

While I agree with the idea of using a separate object, I disagree with
your reasoning. In particular, I don't know of anything which makes it
slower to lock a bigger object.

The main reason (IMO) for avoiding locking on "this" is in case other
classes are locking on the same reference. As soon as you lock on a
reference which other classes have access to, you're at the whim of
what those classes will be doing in terms of deadlocking etc. If you
only ever lock on references which are only available within your own
class, you get a lot more control. You can also have different locks
separate "partitions" of exclusion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel O'Connell [C# MVP]]

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:Xn********************************@207.46.248 .16...

n_**********@mail.com (n_o_s_p_a__m) wrote in
news:1f**************************@posting.google.c om:

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?
lock() is most of the time used as a semaphore for a critical
action. To prevent multiple threads entering the same codeblock, an object
is locked (the parameter to lock()). THe bigger the object, the more time
it costs to lock it. So if you just want to prevent multiple threads
entering a codeblock, you'd better do this:

I don't think thats entirely correct. Nothing I have seen suggests that
lock\Monitor has any issue with object size. Instead Monitor basically uses
a small SyncBlock which is associated with the object on the fly. the
parameter passed to lock\Monitor.Enter() is simply the one which has the
associated SyncBlock so that further calls to lock\Monitor.Enter() can find
that block and handle it. I think the block is disassociated when all lock
blocks end(this is mostly based on my own examiniation of rotor and Jeffery
Richter's column Safe Thread Synchronization[1], so I could easily be
wrong).

I would be interested if you happen to have information as to why object
size matters, however.

The more important reason, IMHO, not to lock on this is that this is
available to other objects. If you have a method that locks on this, a
method in another object(on a different thread) could easily call
lock(myObjectInstanceVariable), thereby creating a potential deadlock in a
very unrelated piece of code. Anytime you perform a lock on a value that is
available to the outside you run the risk of it being locked by code outside
of your control and introducing a deadlock.

1. http://msdn.microsoft.com/msdnmag/issues/03/01/NET/

object uniqueObject = new object();

lock(uniqueObject)
{
// your code
}

Frans.

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Dilip Krishnan]

Frans,
its not really that it costs mroe to lock bigger objects its to
prevent deadlocks with opened monitors on the object and the finalizers,
in the case that the monitor never exits before the object is ready for
finalization
HTH

Frans Bouma [C# MVP] wrote:

n_**********@mail.com (n_o_s_p_a__m) wrote in
news:1f**************************@posting.google.c om:

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?

lock() is most of the time used as a semaphore for a critical
action. To prevent multiple threads entering the same codeblock, an object
is locked (the parameter to lock()). THe bigger the object, the more time
it costs to lock it. So if you just want to prevent multiple threads
entering a codeblock, you'd better do this:

object uniqueObject = new object();

lock(uniqueObject)
{
// your code
}

Frans.

--
Regards,
Dilip Krishnan
MCAD, MCSD.net
dilipdotnet at apdiya dot com

[mikeb]

n_o_s_p_a__m wrote:

I have seen some debate but am not clear on what the problematic
implications of the expression lock(this) are. Microsoft seems to
advocate it, but others seem to be against it.

Pros and cons?

I haven't seen any major arguments about lock( this) - the only problem
I see with it is that the lock potentially has a larger 'granularity'
than might really be needed.

For example, if an object contains an internal cache and some other
value that is unrelated to the cache, and both the cache and the value
can be updated in multiple threads, there's probably no reason to lock
on the entire object when updating the cache - you can lock on the cache
alone.

However, I have seen some discussion on the "lock( typeof( ClassName))"
idiom, indicating that it should not be used (even though it is used in
many Microsoft samples). See:

http://msdn.microsoft.com/library/en...ui06032003.asp

--
mikeb

[Jon Skeet [C# MVP]]

mikeb <ma************@nospam.mailnull.com> wrote:

However, I have seen some discussion on the "lock( typeof( ClassName))"
idiom, indicating that it should not be used (even though it is used in
many Microsoft samples). See:

http://msdn.microsoft.com/library/en...ui06032003.asp

The same arguments presented apply to "this" as well:

<quote>
The basic problem here is that you don't own the type object, and you
don't know who else could access it. In general, it's a very bad idea
to rely on locking an object you didn't create and don't know who else
might be accessing. Doing so invites deadlock. The safest way is to
only lock private objects.
</quote>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too