Why not use this as a lock object in lock

[Tony Johansson]

Hello!

According to the docs it says that lock (this) is a problem if the instance
can be accessed publicly.
Can somebody explain what can happen if I have a lock section and use this
as the lock object like this.
lock(this)
{

}

//Tony

 

[Jeroen Mostert]

According to the docs it says that lock (this) is a problem if the instance
can be accessed publicly.
Can somebody explain what can happen if I have a lock section and use this
as the lock object like this.
lock(this)
{

}

http://haacked.com/archive/2006/08/08/threadingneverlockthisredux.aspx

 

[Arne Vajhøj]

According to the docs it says that lock (this) is a problem if the instance
can be accessed publicly.
Can somebody explain what can happen if I have a lock section and use this
as the lock object like this.
lock(this)
{

}

You can do it.

If someone else locks on the object you can risk a deadlock.

lock(this) has traditionally been frowned on in the .NET world
for that reason.

It is some theoretical bullshit.

Obviously you need to think about what you lock on, but
it is quite general in multithreaded programming that you
need to have the brain "on" not "off".

Arne

 

[Arne Vajhøj]

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.

Something like on a scale from 1 to 10 around -2.



Arne

 

[Arne Vajhøj]

[...]

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

Arne

 

[Arne Vajhøj]

It's only "theoretical bullshit" in the same sense that all "best
practices" advice in programming is "theoretical bullshit".

No.

It is theoretical bullshit because it is not a problem seen
in the real world.

There are a few other best practices that also fell in that
category, but most best practices are actually based
on solving real world problems.

One could say the exact same thing about all of the various idioms,
rules-of-thumb, etc. we use in programming. Just the other day, you
(correctly, IMHO) argued in favor of making fields private. But as long
as someone is careful, what's _really_ the problem with that? None. It's
just "theoretical bullshit" that exposing fields in your class could
cause an issue.

Those two are not very comparable.

It is relative easy to find examples on how breaking encapsulation
by exposing implementation has created problems.

I have never seen or heard about a real world case where
the lock on this has actually created a problem.

Best practices are only true best practices if they solve
real problems.

Best practices that solves non-existing problems are
just crap being propagated blindly without anyone thinking
about it.

The real problem is that it's not possible for any of us humans to be
careful 100% of the time. Our brains don't operate in a strictly "on" or
"off" state; instead, different people have different capacities for
avoiding mistakes, and even a given person has good days and bad days.

When one follows good advice, such as never locking on "this", it helps
avoid certain classes of bugs. Of course, there will always be other
bugs that one can introduce. But one might as well avoid the
easy-to-avoid ones.

Please post a link to an actual case of the problem.

But it's still good advice to keep your locking objects private, so that
one can ensure that when locking on an object,

Unfortunately that is not possible in many of the most interesting
cases where you need locks on multiple instances.

So, don't make it more difficult to reason about the state of your
program. Encapsulate locking in exactly the same way you'd encapsulate
data in fields, and it will be much easier to avoid certain kinds of bugs.

The ability to lock something is not always an internal thing
but something that the caller needs.

Frankly, you do the entire community a great disservice when you call
good advice like that "bullshit".

It is not good advice. It is just copy paste.

Arne

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Harlan Messinger]

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

 

[Arne Vajhøj]

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.

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.

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