lock(this) hangs

[Rainer Queck]

Hello NG,

my application hangs onec a while. When I interrupt the execution (press the
|| button) the debugger shows me a green arrow on a "lock(this)" line.
I first thought, well "deadlock" so I modified my code to find out who locks
the app. Therfore I added a string member "lockOwner" to the class in
question and after each "lock(this)" I set the members value to the method
name like:

lock(this)
{
lockOwner = "Method1";
}
lockOwner = "unlocked";

As I ran into the same hang situation again, I thought, I could now find out
which method causes the problem, but o wonder....
lowOwner showed "unlocked" !!
I tripple checked, that I did not miss a lockOwner assignement.
Now I am out of any ideas to find the cause to my problem.

I would very much appreceate any hints and help on this issue.

Regards
Rainer Queck

[Marc Gravell]

How can I do this?
In VS Pro (or above), bring up the threads window; [Ctrl]+[D],[T] if I
recall; likewise, [Ctrl]+[D],[C] brings up the call stack (change
thread in the thread window to see the different call stacks). If the
key-chords don't work, they are on the Debug->Windows menu.

That will be difficult, since I am working on this project nearly a year now
and it is kind of komplex.
I doubt it, that I can generate a *smal but complete* code from it, that
would show the issue.

This is often the case with threading; fair enough ;-p

Marc

[Marc Gravell]

To highlight; in a winform, a common cause of deadlock is
Control.Invoke - i.e. (just one scenario) a worker thread locks an
object then calls Control.Invoke to get to the UI thread and invoke
something that attempts to lock the same object. The UI thread can't
get the lock, and the worker thread is blocked on the UI. So check for
Control.Invoke methods at the top of the call-stack.

Marc

[Rainer Queck]

Hi Marc,

thanks once more for your help.

"Marc Gravell" <ma**********@gmail.comschrieb im Newsbeitrag
news:9d**********************************@z26g2000 pre.googlegroups.com...

To highlight; in a winform, a common cause of deadlock is
Control.Invoke - i.e. (just one scenario) a worker thread locks an
object then calls Control.Invoke to get to the UI thread and invoke
something that attempts to lock the same object. The UI thread can't
get the lock, and the worker thread is blocked on the UI. So check for
Control.Invoke methods at the top of the call-stack.

Very likely that this is the reason to my issue.
Also your link to "MiscUtil" came just in time sine I decided to rethink my
sync- and locking strategys .
I have read the article, and I think I will make use of SyncLock instead of
lock().
As I saw the SyncLock has a name property. I hope I can "misuse" this to
assign a owner to it, therby knowing who is holding it.

Thanks a lot!
Rainer

[Marra]

You are really opening up a can of nasty worms with multi threaded
programs.

I tend to shy away from them as I find some of my routines are more
than complicated enough without adding in the dangers of threading
them.

The only thing I have used threads on is clearing huge buggers where I
split the task into four threads, each thread clearing a quarter of
the buffer.

[Jon Skeet [C# MVP]]

Marra <cr*************@talktalk.netwrote:

You are really opening up a can of nasty worms with multi threaded
programs.

Threading is certainly difficult - but it's important, and going to be
increasingly so as manufacturers add more and more cores to chips.

I tend to shy away from them as I find some of my routines are more
than complicated enough without adding in the dangers of threading
them.

What do you do to keep UIs responsive? The key to keeping a UI
responsive is to not do significant processing on the UI thread. That
pretty much necessitates threading in many applications.

You certainly need to be careful when threading, and it's worth
considering whether or not something really needs to be multi-threaded
before making it so - but it's also not something to be avoided like
the plague.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Marc Gravell]

On Dec 30, 6:06*pm, Marra <[e-mail]:

You are really opening up a can of nasty worms with multi threaded
programs.

The can exists either way. It is just a different label ;-p As Jon
already said, keeping the UI responsive is a major aim in non-trivial
apps (and DoEvents() is *not* a good solution to this) - but I agree
that *improper* use of threading can cause major headaches. There are
several approaches you can use to keep things simple - for example, in
a simple worker/UI scenario there is often no need for the two to
share data except when throwing data onto the UI (via Invoke/
BeginInvoke) - which can remove the need for a lot of complicated
locking.

But more than this - as PCs become more CPU rich (multiple slower
cores rather than a single speedy core), ginving *suitable*
consideration to threading is a good skill to learn. And that doesn't
mean "multi-thread everywhere". Equally, frameworks like PFX (or
Parallel Extensions as it is now) show where *some* (but definitely
not all) code is heading.

Marc

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Rainer Queck wrote:

>Second; I don't recommend locking on "this"; you can never know who
else is locking any object, so it is a poor choice. For less chance of
deadlocks, keep a private object for the purpose - or sometimes you
can re-use a handy *private* readonly object (such as an inner
collection that is not exposed).

In general you are right.
In my case I KNOW that nobody else is locking "this" object, becaues in my
project I am using lock(this) only inside a class.

No, you can't KNOW that. As long as you are using a publically reachable
object, any other code can potentially use the same object for locking.

If you instead use a private object for locking, you KNOW that no other
code can use the same object for locking.

--
Göran Andersson
_____
http://www.guffa.com