Why not use this as a lock object in lock
in [CSharp]
|
Prev: SoundPlayer
Next: Error "ActiveX control '8856f961-340a-11d0-a96b-00c04fd705a2'cannot be instantiated because the current thread is not in a single-threaded apartment."
From: Peter Duniho on 21 Jun 2010 01:09 Arne Vajhøj wrote: > On 20-06-2010 14:45, Peter Duniho wrote: >> Arne Vajhøj wrote: >>> [...] >>>> http://haacked.com/archive/2006/08/08/threadingneverlockthisredux.aspx >>> >>> Quote: >>> >>> "A while ago I wrote that you should never lock a value type ..." >>> >>> I think that gives a good indication of the technical level >>> of the advice. [...] >> >> Perhaps you could be more specific. The advice to never lock on a value >> type is actually very good advice, > > Given that the C# compiler gives an error when attempting to > do it, then ... The "lock" statement is not the only way to lock (there is no error if you use the Monitor class directly), and the compiler error even when using the "lock" statement is easily bypassed simply by casting the variable to object. Do not underestimate the ability of people to circumvent the compiler's attempts to keep you from doing some stupid. The advice to not lock a value type is valid, whether or not the compiler tries to help you avoid doing it. Pete
From: Peter Duniho on 21 Jun 2010 01:16 Arne Vajh�j wrote: > [...] > I have never seen or heard about a real world case where > the lock on this has actually created a problem. You certainly have an over-confident sense of the value of your own experiences as applying to every other programmer in existence. The fact is, the question of using "this" for a lock is important enough that the implementation for compiler-generated event accessors was fixed in the C# 4.0 compiler so that it no longer locks on "this". I'll take the experiences of those who are actually implementing .NET and the C# compiler over yours any day when it comes to answering questions about what's an important rule to follow or not when writing ..NET code. Pete
From: Arne Vajhøj on 21 Jun 2010 22:41 On 21-06-2010 01:09, Peter Duniho wrote: > Arne Vajhøj wrote: >> On 20-06-2010 14:45, Peter Duniho wrote: >>> Arne Vajhøj wrote: >>>> [...] >>>>> http://haacked.com/archive/2006/08/08/threadingneverlockthisredux.aspx >>>> >>>> Quote: >>>> >>>> "A while ago I wrote that you should never lock a value type ..." >>>> >>>> I think that gives a good indication of the technical level >>>> of the advice. [...] >>> >>> Perhaps you could be more specific. The advice to never lock on a value >>> type is actually very good advice, >> >> Given that the C# compiler gives an error when attempting to >> do it, then ... > > The "lock" statement is not the only way to lock (there is no error if > you use the Monitor class directly), The code example he gives is: private bool isDisposed = false; //... code... ~MyClass() { lock(isDisposed) { if(!isDisposed) { //Do Stuff... } } } > and the compiler error even when > using the "lock" statement is easily bypassed simply by casting the > variable to object. But in that case you are not really locking on a value type but on the object containing the value. > Do not underestimate the ability of people to circumvent the compiler's > attempts to keep you from doing some stupid. The advice to not lock a > value type is valid, whether or not the compiler tries to help you avoid > doing it. I am not denying that people can do silly things. I am just saying that I have little respect for blog writers that argue against writing code that does not even compile. Arne
From: Arne Vajhøj on 21 Jun 2010 22:51 On 21-06-2010 01:16, Peter Duniho wrote: > Arne Vajh�j wrote: >> [...] >> I have never seen or heard about a real world case where >> the lock on this has actually created a problem. > > You certainly have an over-confident sense of the value of your own > experiences as applying to every other programmer in existence. When I write "seen or heard about" I do not limit it to personal experience. In fact I would not even use the term "heard about" for personal experience. So that observation is rather ridiculous. > The fact is, the question of using "this" for a lock is important enough > that the implementation for compiler-generated event accessors was fixed > in the C# 4.0 compiler so that it no longer locks on "this". > > I'll take the experiences of those who are actually implementing .NET > and the C# compiler over yours any day when it comes to answering > questions about what's an important rule to follow or not when writing > .NET code. But now we are back at that this so called "best practice" is not backed by any known examples - it is just assumed that because some people have stated that then there must be some reason behind it. Writing software should be science/engineering not religion. And it is as if there is a lack of real problems to look for solutions for. Arne
From: Harlan Messinger on 22 Jun 2010 00:50
Arne Vajh�j wrote: > On 21-06-2010 01:16, Peter Duniho wrote: >> Arne Vajh�j wrote: >>> [...] >>> I have never seen or heard about a real world case where >>> the lock on this has actually created a problem. >> >> You certainly have an over-confident sense of the value of your own >> experiences as applying to every other programmer in existence. > > When I write "seen or heard about" I do not limit it to > personal experience. > > In fact I would not even use the term "heard about" for > personal experience. > > So that observation is rather ridiculous. > >> The fact is, the question of using "this" for a lock is important enough >> that the implementation for compiler-generated event accessors was fixed >> in the C# 4.0 compiler so that it no longer locks on "this". >> >> I'll take the experiences of those who are actually implementing .NET >> and the C# compiler over yours any day when it comes to answering >> questions about what's an important rule to follow or not when writing >> .NET code. > > But now we are back at that this so called "best practice" is > not backed by any known examples Known by you, you mean? What knowledge could you have that would preclude other people from knowing of real-life instances of this kind of locking problem that haven't come to your attention? > - it is just assumed that > because some people have stated that then there must be some > reason behind it. The reason is obvious: all you need is one programmer creating an object from your class and deciding that that object is a good thing to lock on, and it will screw up your entire, carefully tuned internal synchronization scheme based on a lock on that object. Why would you assume that in the entire past and entire future of the planet, this *wouldn't* happen? > > Writing software should be science/engineering not religion. Interesting philosophy: in order to avoid treating software creation as a religion, one should avoid all practices that would be best practices IF failure to follow them would ever lead to a problem, IF one places one's faith in the proposition that on the contrary, failure to follow them will never lead to a problem. The problem is that *that* philosophy sounds like a religion. |