Failure of SetEvent to wake threads....
Carl R
The problem we are experiencing is this:
We have a manual reset event object. We use it to signal 1 to n threads
of when it is time to terminate. The threads do a
MsgWaitForMultipleObjects. They wait on a queue semaphore, and the
shutdown event. If the queue semaphore is what signalled, they pop an
item from the queue and service it, then they go back to the
MsgWaitForMultipleObjects. If the shutdown event is signalled, all
threads should wake, and shutdown. However, this does not always happen.
Sometimes a thread misses the event, and is force terminated (our code
force terminates the threads that have failed to shutdown after a timeout
waiting on the thread HANDLE – this is because this is deemed to be an
error condition.)
MSDN (Q173260) contains the following:
"
SYMPTOMS
Threads waiting on a synchronization object may not be released (for
example, by PulseEvent() or a SetEvent()/ResetEvent() combination) while
you are debugging an application under Windows NT.
CAUSE
This symptom is an anomaly related to the debug environment under Win32.
It will only occur under a Win32 debugger, including any version of the
Visual C++ debugger and WinDBG.
"
The article claims that it is only an issue under a Win32 debugger. We
seem to be experiencing the problem outside of the debugger also.
We have test harnesses that run fine, all threads exiting the majority of
times cleanly. ie. All threads pick up the shutdown event. Then for no
reason we can fathom, a thread will appear to miss the shutdown event,
resulting in a forced termination.
We would like to know:
1. Are we the only ones getting this behaviour outside of a Win32
debugger.
2. A sure fire solution. Like MSDN says, the work around (a Sleep(0)
before signalling the event) does not always work.
Carl Knight.
TAB,
106-110 Jackson St.
Petone.
Carl....@tab.co.nz or
knig...@paradise.net.nz
johnso...@my-deja.com
If you use SetEvent and there is no ResetEvent in any of the threads
involved, then there should not be a problem. But, if the problem
continues, you can have a finite timeout on the MsgWait call and have
threads loop back to test test some sort of condition, such as a flag,
set by the signaling thread (the flag variable should be volatile).
If you use PulseEvent, then you may have a race condition, or "missed
signal," as only the threads that have already blocked at the MsgWait
call will be released. A thread arriving later will block (unless no
threads were waiting, in which case exactly one late arriving thread
will be released). If you are using PulseEvent (and there are good
reasons to do so in certain circumstances), then you will need a finite
timeout on the MsgWait. As above, threads that time out then need to
loop back and test some sort of condition, such as a flag, set by the
signaling thread (the flag should be volatile).
Hoping that helps,
Johnson (John) M. Hart
jmh...@world.std.com
PS and Editorial Comment: Win32 events are a bad idea and poorly
designed, IMHO. Your problem illustrates the difficulties. What is
really needed are condition variables, as in Pthreads. With care,
condition variables can be emulated in Win32. I've posted a discussion
of this at http://world.std.com/~jmhart/critcom.htm, near the bottom
(last major section) and plan to add more. You may also want to see
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
In article <20001108...@mis.configured.host>,
Carl R <knig...@paradise.net.nz> wrote:
> OS: Windows NT 4.0, Service Pak 5, Visual C++ 6.0
>
> The problem we are experiencing is this:
>
> We have a manual reset event object. We use it to signal 1 to n
threads =
>
> of when it is time to terminate. The threads do a=20
> MsgWaitForMultipleObjects. They wait on a queue semaphore, and the=20
> shutdown event. If the queue semaphore is what signalled, they pop
an=20=
>
> item from the queue and service it, then they go back to the=20
> MsgWaitForMultipleObjects. If the shutdown event is signalled, all=20
> threads should wake, and shutdown. However, this does not always
happen.=
> =20
> Sometimes a thread misses the event, and is force terminated (our
code=20=
>
> force terminates the threads that have failed to shutdown after a
timeou=
> t=20
> waiting on the thread HANDLE =96 this is because this is deemed to be
an=
> =20
> error condition.)
>
> MSDN (Q173260) contains the following:
>
> "
>
> SYMPTOMS
> Threads waiting on a synchronization object may not be released
(for=20=
>
> example, by PulseEvent() or a SetEvent()/ResetEvent() combination)
while=
> =20
> you are debugging an application under Windows NT.=20
>
> CAUSE
> This symptom is an anomaly related to the debug environment under
Win32.=
> =20
> It will only occur under a Win32 debugger, including any version of
the =
>
> Visual C++ debugger and WinDBG.=20
>
> "
>
> The article claims that it is only an issue under a Win32 debugger.
We=20=
>
> seem to be experiencing the problem outside of the debugger also.
>
> We have test harnesses that run fine, all threads exiting the
majority o=
> f=20
> times cleanly. ie. All threads pick up the shutdown event. Then for
no=20=
>
> reason we can fathom, a thread will appear to miss the shutdown
event,=20=
>
> resulting in a forced termination.
>
> We would like to know:=20
> 1. Are we the only ones getting this behaviour outside of a
Win32=20
> debugger.
> 2. A sure fire solution. Like MSDN says, the work around (a
Sleep(0)=20=
>
> before signalling the event) does not always work.
>
> Carl Knight.
> TAB,
> 106-110 Jackson St.
> Petone.
> Carl....@tab.co.nz or
> knig...@paradise.net.nz
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Maxim S. Shatskih
> threads loop back to test test some sort of condition, such as a flag,
> set by the signaling thread (the flag variable should be volatile).
Even more better:
- redesign the app, use some WM_xxx message instead of event signaling and
thus GetMessage instead of MsgWaitxxx. This is much simpler and more
logical.
Max