How can WaitOne hang when used with a timeout?

[Ed Sutton]

Can any one please offer any theories on how ManualResetEvent.WaitOne
can hang when used with a timeout?

When I notice my USB/Serial devices are no longer receiving
communications, I hit break all, and one of the threads is hanging at:

bool replyReceived =
readerCommand.SignalReply.WaitOne(readerCmd.rxTime OutMs, false);

Apparently the 1000ms rxTimeOutMs is not working. I have two threads
that wait on this event. This problem has been plaguing me for a long
time. I can not understand how the timeout does not work. If it is a
threading issue, I can not see what it is.

Thanks in advance for any theories or suggestions.

-Ed

[andrew queisser]

"Ed Sutton" <de******************@hotmail.com> wrote in message
news:eY**************@TK2MSFTNGP02.phx.gbl...

Can any one please offer any theories on how ManualResetEvent.WaitOne can
hang when used with a timeout?

When I notice my USB/Serial devices are no longer receiving
communications, I hit break all, and one of the threads is hanging at:

bool replyReceived =
readerCommand.SignalReply.WaitOne(readerCmd.rxTime OutMs, false);

Apparently the 1000ms rxTimeOutMs is not working. I have two threads that
wait on this event. This problem has been plaguing me for a long time. I
can not understand how the timeout does not work. If it is a threading
issue, I can not see what it is.

Thanks in advance for any theories or suggestions.

Other than checking whether rxTimeOutMs contains a sane value when you enter
the WaitOne my only suggestion would be to try passing 'true' for the second
parameter.

Andrew

[Ed Sutton]

andrew queisser wrote:

readerCommand.SignalReply.WaitOne(readerCmd.rxTime OutMs, false);

Other than checking whether rxTimeOutMs contains a sane value when you enter
the WaitOne my only suggestion would be to try passing 'true' for the second
parameter.

Thank you for your reply.

Yes, rxTimeOutMs is set to 1000 milliseconds.

I do not understand why setting the exitContext parameter to true would
make the timeout work as I expect. I expect it to wait until the
ManualResetEvent is signaled or the timeout occurs. The problem is the
timeout elapses yet it is never signaled.

Any additional thoughts are much appreciated.

-Ed

[andrew queisser]

"Ed Sutton" <de******************@hotmail.com> wrote in message
news:OQ**************@TK2MSFTNGP03.phx.gbl...

andrew queisser wrote:

readerCommand.SignalReply.WaitOne(readerCmd.rxTime OutMs, false);

Other than checking whether rxTimeOutMs contains a sane value when you
enter the WaitOne my only suggestion would be to try passing 'true' for
the second parameter.

Thank you for your reply.

Yes, rxTimeOutMs is set to 1000 milliseconds.

I do not understand why setting the exitContext parameter to true would
make the timeout work as I expect. I expect it to wait until the
ManualResetEvent is signaled or the timeout occurs. The problem is the
timeout elapses yet it is never signaled.

Any additional thoughts are much appreciated.

Hi Ed,

Don't really know either, I was just looking at the two parameters to the
function. If you do have a good value for rxTimeoutMs, the only other knob
to play with is the context parameter so I just wanted to make sure you did
try changing that value.

I never fully understood what the exitContext parameter does although I
often use WaitOne. After reading your post I decided it was time to
understand what exitContext means and now I have at least some understanding
of its function. I'm not sure if it really is possible to lead to a deadlock
but perhaps there's another thread running in the same context that the
WaitOne thread was running in. That could lead to a situation where WaitOne
wakes up due to timeout but cannot run because it cannot get into the
context. However, I would expect a deadlock to be more likely when you set
the exitContext to true.

Andrew