Re: WaitForMultipleObjects returning ERROR_INVALID_HANDLE (RESOLVED)
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:esUSDHFGIHA.1212@TK2MSFTNGP05.phx.gbl...
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.
Although, if you listen from the same thread, set the event before starting
an operation, the functions like ReadFile, WriteFile will reset the event if
the operation goes overlapped.
You do not need to reset the event.
"ReadFile resets the event specified by the hEvent member of the OVERLAPPED
structure to a nonsignaled state when it begins the I/O operation.
Therefore, the caller does not need to do that."
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