473,324 Members | 1,646 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

what's wrong with lock(this) ?

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
Nov 16 '05 #1
6 7286
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
Nov 16 '05 #2
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
Nov 16 '05 #3

"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

Nov 16 '05 #4
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
Nov 16 '05 #5
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
Nov 16 '05 #6
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
Nov 16 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: n_o_s_p_a__m | last post by:
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? ...
4
by: Max Adams | last post by:
All, I have a multithreaded app (using threadpool). I was under the illusion that where I used lock( this ) around a segment of code that only one thread would be allowed access to that segment...
2
by: yaron | last post by:
Hi, Does MethodImpl Synchronized attribute is like lock(this) ? i mean that a call to Monitor.PulseAll(this) from a Synchronized method will trigger other thread that call to Monitor.Wait(this)...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.