c# Thread problem

On Jul 4, 12:14 pm, Tom Spink <tsp...@gmail.c omwrote:

>The reason you're getting a deadlock is because you're waiting on a lock
that you already hold.

No, that's the *only* place you can call Wait. If you call
Monitor.Wait on a lock you don't already hold, an exception will be
thrown.

> It looks like you need to implement the
Producer/Consumer pattern here, as has been mentioned. Take a look here
for an example:

http://www.betasafe.com/code?view=prcon

Note that that code *also* calls Wait on a lock it already holds.

Jon

There don't have to be two explicit locks in the code though. Suppose
the update(gMsg) code included a call to Control.Invoke, and at the
time the UI was waiting to enqueue an extra message... that would
cause a deadlock, certainly.

On Wed, 04 Jul 2007 05:27:52 -0700, Jon Skeet [C# MVP] <s...@pobox.com >
wrote:

There don't have to be two explicit locks in the code though. Suppose
the update(gMsg) code included a call to Control.Invoke, and at the
time the UI was waiting to enqueue an extra message... that would
cause a deadlock, certainly.

And in fact, in my experience using Invoke() with a lock is the most
common source of deadlock in .NET code. :)

On 7 5 , 2 40 , "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Wed, 04 Jul 2007 05:27:52 -0700, Jon Skeet [C# MVP] <s...@pobox.com >
wrote:

There don't have to be two explicit locks in the code though. Suppose
the update(gMsg) code included a call to Control.Invoke, and at the
time the UI was waiting to enqueue an extra message... that would
cause a deadlock, certainly.

And in fact, in my experience using Invoke() with a lock is the most
common source of deadlock in .NET code. :)

Actually I'm using invoke() to update control like textBox, Label with
lock...
According to debugger, deadlock may happen by both of invoke to
update label and lock for push a data to QUEUE
I need to update lable and also need to receive message by using
thread..

Is there any solution?

On Jul 5, 10:01 am, cty0...@gmail.c om wrote:

On 7 5 , 2 40 , "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Wed, 04 Jul 2007 05:27:52 -0700, Jon Skeet [C# MVP] <s...@pobox.com >
wrote:

There don't have to be two explicit locks in the code though. Suppose
the update(gMsg) code included a call to Control.Invoke, and at the
time the UI was waiting to enqueue an extra message... that would
cause a deadlock, certainly.

And in fact, in my experience using Invoke() with a lock is the most
common source of deadlock in .NET code. :)

Actually I'm using invoke() to update control like textBox, Label with
lock...
According to debugger, deadlock may happen by both of invoke to
update label and lock for push a data to QUEUE
I need to update lable and also need to receive message by using
thread..

Is there any solution?

Yes:

1) Pull the call to update out of the lock block. (This would also
naturally occur as part of refactoring the queue to its own task-
agnostic class.)
2) Use BeginInvoke instead of Invoke.

Jon- -

- -

I can not understand all ^^
I need to update function call during exist QUEUE data.. to do this,
updata must be lock block..

get the data until QUEUE empty and update GUI screen.
if update function pull out of lock block.. hmmm.... Actually I do not
know how to implement the code..

If I use begininvoke instead of invoke, I do not need to pull out
upate() from lock block??
I will try to find out about begininvoke..

It's Big problem for me -.-;;

On Jul 5, 10:21 am, cty0...@gmail.c om wrote:

I can not understand all ^^
I need to update function call during exist QUEUE data.. to do this,
updata must be lock block..

No - you *fetch* the item while the queue is locked, but after you've
fetched the update you don't need to hold the lock any more. At least,
if you think you do, please explain why.

get the data until QUEUE empty and update GUI screen.
if update function pull out of lock block.. hmmm.... Actually I do not
know how to implement the code..

Just move the call to "update" to after the brace ending the lock.

If I use begininvoke instead of invoke, I do not need to pull out
upate() from lock block??
I will try to find out about begininvoke..

It's Big problem for me -.-;;

You don't *have* to pull update() out of the lock block, but you
should anyway because conceptually you don't need the lock while
you're updating.

Jon

I have changed my code like follow to test. Is this what you means?

>
private void threadJob()
{
GUIMsg gMsg;

lock (queueLock)
{
while (GuiMsgQueue.Co unt != 0)
{
gMsg = GuiMsgQueue.Deq ueue();
update(gMsg);

}
}
}

<cty0...@gmail. comschrieb im Newsbeitragnews :11************ **********@z28g 2000prd.googleg roups.com...
What he meant is, change youre original threadJob:

public void threadJob()
{
GUIMsg gMsg;

while (true)
{
Thread.Sleep(10 0);
lock (queueLock)
{
while (GuiMsgQueue.Co unt == 0)
Monitor.Wait(qu eueLock);

gMsg = GuiMsgQueue.Deq ueue();
}
update(gMsg); //This line is moved.
}
}

After the GuiMsgQueue.Deq ueue() there is no need to hold the lock.

From your code:

private void threadJob()
{
GUIMsg gMsg;

lock (queueLock)
{
while (GuiMsgQueue.Co unt != 0)
{
gMsg = GuiMsgQueue.Deq ueue();
update(gMsg);

Here the update ist still inside of the lock. And the lock is even hold over
several dequeues. By this you prevent enqueueing, till the consumer has
emptied the queue.

Christof

}
}
}- -

- -