Sorry, the question remains

[Zach]

The code below was taken from an MSDN example.
The example contains explantory lines. Nevertheless
I do not understand the use of the while loop. Because
of the Pulse within the loop, I would expect the loop
to end after the dequeue. If that is correct this would
be one off situation, I therefore don't understand why
a loop was used.

There are two threads in the example.

public void SecondThread()
{
lock(m_smplQueue)
{
Monitor.Pulse(m_smplQueue);
while(Monitor.Wait(m_smplQueue,1000))
{
int counter = (int)m_smplQueue.Dequeue();
Console.WriteLine(counter.ToString());
Monitor.Pulse(m_smplQueue);
}
}
}

 

[Chris Hyde]

I don't believe the while loop is used to iterate through items in the
queue; the two comment lines in the original MSDN article really explain
what the while loop is doing:

//Wait in the loop, while the queue is busy.
//Exit on the time-out when the first thread stops.

Basically, the while loop is causing a halt in execution (on the current
thread), until such time as the current thread can get an exclusive lock
on the m_smplQueue object, or 1 second of time passes (whichever occurs
first). This is carried out by the Monitor.Wait(m_smplQueue,1000) call.
If an exclusive lock is acheived, the code inside the loop runs. If
an exclusive lock is NOT achieved, essentially, the method ends.

Here is a link to the full sample source:
http://msdn.microsoft.com/library/d...rlrfsystemthreadingmonitorclasspulsetopic.asp

And, the description of the Monitor.Wait method:
http://msdn.microsoft.com/library/d...rlrfSystemThreadingMonitorClassWaitTopic2.asp

HTH...
Chris

 

[Guest]

After the dequeue, the thread loops back to wait for its next turn again.

 

[Zach]

After the dequeue, the thread loops back to wait for its next turn again.

I think the penny has finally dropped:
Because of the Pulse, the wait-status is maintained, whilst at
the same time the other thread is activated. The loop continues
after the other thread Pulses. Right?

 

[Zach]

I don't believe the while loop is used to iterate through items in the
queue; the two comment lines in the original MSDN article really explain
what the while loop is doing:

//Wait in the loop, while the queue is busy.
//Exit on the time-out when the first thread stops.

Yes, you are right, the example contains comment.
I said in my posting(s) that I was aware of that comment,
but that I didn't understand it. But I think a glass of wine
helped See my response to Tu-Thach. See if you agree
with what I said to him, and thanks for your response.

Zach.

 

[Jon Skeet [C# MVP]]

I don't believe the while loop is used to iterate through items in the
queue; the two comment lines in the original MSDN article really explain
what the while loop is doing:

//Wait in the loop, while the queue is busy.
//Exit on the time-out when the first thread stops.

Basically, the while loop is causing a halt in execution (on the current
thread), until such time as the current thread can get an exclusive lock
on the m_smplQueue object, or 1 second of time passes (whichever occurs
first). This is carried out by the Monitor.Wait(m_smplQueue,1000) call.
If an exclusive lock is acheived, the code inside the loop runs. If
an exclusive lock is NOT achieved, essentially, the method ends.

No, that's not quite right. The thread will re-acquire the lock
*either* way before the Wait method returns. It's whether or not
m_smplQueue has been pulsed or not since the Wait started which is
being tested.

 

[Zach]

No, that's not quite right. The thread will re-acquire the lock
*either* way before the Wait method returns. It's whether or not
m_smplQueue has been pulsed or not since the Wait started which is
being tested.

I was assuming that the loop will do go-arounds when
/ as soon as, it is able to do so, given the action in the
other thread.

 

[Jon Skeet [C# MVP]]

I was assuming that the loop will do go-arounds when
/ as soon as, it is able to do so, given the action in the
other thread.

It will, as soon as it is able to do so - but Wait will not return
until the lock has been reacquired, whether or not the monitor was
pulsed in the meantime.

 

[Zach]

It will, as soon as it is able to do so - but Wait will not return
until the lock has been reacquired, whether or not the monitor was
pulsed in the meantime.

OK, thanks,
Zach.

 

[Chris Hyde]

It will, as soon as it is able to do so - but Wait will not return

until the lock has been reacquired, whether or not the monitor was
pulsed in the meantime.

What about the 1000 ms timeout though? What if the lock has not been
reacquired before the timeout is reached (ok, probably not going to
happen in the simple example, but what about in a similar situation
where perhaps MORE intensive work was being performed)?

Chris

 

[Jon Skeet [C# MVP]]

What about the 1000 ms timeout though? What if the lock has not been
reacquired before the timeout is reached (ok, probably not going to
happen in the simple example, but what about in a similar situation
where perhaps MORE intensive work was being performed)?

Then it waits until it's reacquired before returning. If something else
has the lock out indefinitely, the method won't return. The MSDN docs
are currently confusing on this matter, and are being reworked.
(There's a thread in .framework about this somewhere, although I can't
remember the name.)