For what it worth, I don't expect PostQueuedCompletionStatus/GetQCS to be
any cheaper than PostThreadMessage/GetMessage. Both are likely to incure
similar overhead in terms of kernel roundtrips, etc. I would be curious to
see any profiling results, though.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
These days, I would never consider a Mutex[CRITICAL_SECTION]/Semaphore
example except in
very rare situations; I'd use an I/O Completion Port and
PostQueuedCompletionStatus/GetQueuedCompletionStatus, which saves all the
hassles.
Efficiency is an issue only if it matters. I can process a huge number of
messages per
second using PQCS/GQCS, and it scales nicely.
Rasoning about auto-reset events and events in general means you end up
creating solutions
which are both unnecessarily complicated and probably buggy. There's
someone in the DDK
group who keeps advising people to write their own "more efficienct"
synchronization
primitives, and several of his postings have been wrong (Queued Spin Locks
int he kernel
are about as fast as you can get...)
joe
On Fri, 11 Jan 2008 22:48:26 -0600, "Doug Harrison [MVP]" <dsh@mvps.org>
wrote:
On Fri, 11 Jan 2008 19:59:17 -0800, "Alexander Grigoriev"
<alegr@earthlink.net> wrote:
What's wrong with just fully draining a queue after an event was
signalled?
Perhaps nothing, but you have to think of it. The algorithm posted by the
OP did not specify the queue would be drained.
I don't see any advantage of a semaphore. For a semaphore you'll have one
mandatory WFSO per a queued item, and for an event in high load condition
you'll have several items per WFSO, which reduces overhead somewhat.
You have to protect the queue in any case. You can use a lock-free
single-linked list, though, grab it completely and then process at your
leisure, without need of any synchronization.
You don't have to receive an event and grab a mutex in an atomic
operation.
Yes, spurios wakeups are then possible, and it's trivial to handle.
Again, you have to think of it. The algorithm posted by the OP did not
include an emptiness check by the reader.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm