How did it dead lock?

[euan_woo]

Hi,
Sometimes my program stops and when I break it I see 2 threads both
waiting at a lock statement trying to lock the same object. If I look
up the call stack of these threads there aren't any other calls to lock
statements so I don't see how it's possible for anything to be locked.

Can anyone explain this to me?

Thanks

[Brian Gideon]

Hi,

Is it possible that another thread other than the 2 you just mentioned
is holding the lock?

Brian

eu******@hotmai l.com wrote:

Hi,
Sometimes my program stops and when I break it I see 2 threads both
waiting at a lock statement trying to lock the same object. If I look
up the call stack of these threads there aren't any other calls to lock
statements so I don't see how it's possible for anything to be locked.

Can anyone explain this to me?

Thanks

[euan_woo]

Hello,

I don't think so, there aren't any other threads with source code
available
Brian Gideon wrote:

Hi,

Is it possible that another thread other than the 2 you just mentioned
is holding the lock?

Brian

eu******@hotmai l.com wrote:

Hi,
Sometimes my program stops and when I break it I see 2 threads both
waiting at a lock statement trying to lock the same object. If I look
up the call stack of these threads there aren't any other calls to lock
statements so I don't see how it's possible for anything to be locked.

Can anyone explain this to me?

Thanks

[Naveen]

If you are trying to lock(this) then it can lead in to dead locks. Did
you try using SOS/Windbg to identify the dead lock and the stack trace?
Also post a smaple code.

[euan_woo]

Hello,

thanks for the help.

I am trying to lock(this) and that's where one of the threads stops.
The other thread stops while trying to lock the same object although
this time it isn't 'this'.
If I can't lock(this) then what should I do?

If it hangs again how do I use Windbg to help me?

Thanks again!

[Naveen]

Here is reason as to why you shouldnt be using lock(this)
http://blogs.msdn.com/bclteam/archiv.../20/60719.aspx

and i guess you would have to learn how to use windbg to use to detect
dead locks. There are quite a lof of resources on the web.

[Jon Skeet [C# MVP]]

<eu******@hotma il.com> wrote:

I am trying to lock(this) and that's where one of the threads stops.
The other thread stops while trying to lock the same object although
this time it isn't 'this'.
If I can't lock(this) then what should I do?

See http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

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

[Helge Jensen]

Naveen wrote:

Here is reason as to why you shouldnt be using lock(this)
http://blogs.msdn.com/bclteam/archiv.../20/60719.aspx

Complicating your code to defend against outside misuse is a loosing battle.

The solution to bad-outside-code is to let the bad-outside-coders accept
responsibility for their actions and develop their skill (if possible).
Not to spend unlimit development-time, readability and code-complexity,
up front.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Jon Skeet [C# MVP]]

Helge Jensen <he**********@s log.dk> wrote:

Naveen wrote:

Here is reason as to why you shouldnt be using lock(this)
http://blogs.msdn.com/bclteam/archiv.../20/60719.aspx

Complicating your code to defend against outside misuse is a loosing battle.

The solution to bad-outside-code is to let the bad-outside-coders accept
responsibility for their actions and develop their skill (if possible).
Not to spend unlimit development-time, readability and code-complexity,
up front.

If you buy that argument, would you suggest that everything should be
public, too?

Locking on explicit lock objects doesn't take unlimited development
time, nor does it impact readability or code complexity. Indeed, it
adds flexibility, and can allows more useful locking strategies, which
can detect deadlocks and offer timeouts, too:
http://www.pobox.com/~skeet/csharp/m.../locking.shtml

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

[Helge Jensen]

Jon Skeet [C# MVP] wrote:

If you buy that argument, would you suggest that everything should be
public, too?
Yes, I pretty much do. A side-benefit is much less complicated white-box
testing, since the "hiding" of implementation of state is only a hint,
not enforced.

Where possible, also outside computing, I prefer accountability to
prevention.

I admit that I occasionally declare members protected, when I know they
will change implmentation/signature within a short timeframe, or if they
are helper-functions local to the class -- since C# have no free
functions and these helpers aren't part of the behaiour of the class.

For code without security implications I believe in documenting the
risks and letting the user decide.

Prefixing with "_" can be enough documentation that this method or that
member is not for casual use, if that practice is well enough known in
the context.

I have yet to see a real example where private methods or properties do
any real good.
Locking on explicit lock objects doesn't take unlimited development
No, but it does require the programmer to do something more complicated.
Rules accumulate.

I don't particularly object to the use of an explicit lock-object. What
I don't like is stuff like:

"We strongly discourage the use of lock(this). Since other, completely
unrelated code can choose to lock on that object as well"

Which blanket states that a practice should be followed. I don't see any
other reason stated anywhere in the article.

If someone lock(x) on an object, what are they expecting?

lock(this) is preferrable in many cases, most notably those where a
data-structure internally need to lock, but callers also occasionally
need to mutually exclusively invoke multiple methods without intervention.
time, nor does it impact readability or code complexity. Indeed, it
adds flexibility, and can allows more useful locking strategies, which
I am well aware that lock(this) isn't the solution to all locking. But
it's not a bad practice that needs to be banned or workarounded either.
can detect deadlocks and offer timeouts, too:
And if those properties are needed, then by all means implement them.

I have come to prefer simplicity over almost anything, even correctness
upto a point. If it's complicated, it's probably wrong or bug-filled --
if it's simple then it may just be correct.

A very gifted co-worker and the C2 wiki: http://c2.com/cgi/wiki have
turned me from my old habits of closing everything I didn't see a use
for to a practice where I honestly present everything along with hints
about which risks are taken by using a specific level of knowledge about
the implementation.
http://www.pobox.com/~skeet/csharp/m.../locking.shtml

This link seems to be broken? i get 404.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-