Re: WaitForMultipleObjects + Semaphore Makes Me Uncomfortable

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Le Chaud Lapin <jaibuduvin@xxxxxxxxx> wrote:

I imagine a situation where WaitForMultipleObjects is used against a
plurality of synchronization objects, and at least one of the
synchronization objects is a semaphore guarding a queue. If the mode
of the call is "wait for any object to be signaled", then it is
conceivable that Windows will indicate that a non-semaphore object was
the first to be signaled signaled, while, in addition, the semaphore
also triggered, but the programmer will have no way of knowing that
the semaphore too was signaled. In this case, there will result a
disparity between the count of the semaphore and the count of the
elements in the queue.

No. If you say "wait for any object to be signaled", the return code tells
you which of the items you were waiting for got signaled. If a
non-semaphore gets signaled, then it would be a simple programming error
for you to process an item from the queue. Instead, the next time you get
around to WaitForMultipleObjects, it will return immediately with the
indication that the semaphore was signaled. Only then you can handle the
semaphore.

This seems conceptually erroneous to me, or suspicious at least. In
my current program, it is not an issue, as, by coincidence, when this
situation occurs, I simply kill the entire queue and the semaphore
along with it. But this is more fortune than deliberate design. I am
sure I can think of situations where it would be a PITA.

It's only a problem if your program has a bug.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
.

Quantcast