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: Arne Vajhøj on 28 Jun 2010 22:29
On 22-06-2010 00:50, Harlan Messinger wrote:
> Arne Vajh�j wrote:
>> On 21-06-2010 01:16, Peter Duniho wrote:
>>> 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?

Yes.

> 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?

I am following 5 different .NET forums for many years. I have
never seen a problem posted.

But feel free to post a bunch of links to cases of problems.

BTW, I think I have already suggested that a couple of
times.

Either people here want to keep it a secret from me or
they don't know any cases either.

>> - 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?

I hope that it would happen!

Some code in a method in the class have to modify some state of the
object and lock on the object.

Some other code outside the class have to modify the state of
the object and lock on the object.

Sure they interact.

But that is desired behavior.

Having the internal code lock on another object could
result in data corruption.

In general I prefer the risk of a deadlock over the risk
of data corruption.

If somebody don't believe in that, then there are a very simple
solution: just don't use any locks at all.

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

I am not quite sure that I understand that long sentence.

Basing best practices on real problems not something that you have
heard from someone that have heard from someone is engineering
not religion.

As demonstrated above then you assumption about following the
practice will never lead to a problem is simply wrong.

(and I think we can find examples where locking on different
objects has resulted in data corruption - that is not theoretical)

Arne

First  |  Prev  | 
Pages: 1 2 3
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."