Re: Is there a way to get the current semaphore count?
"jeffareid" <jeffareid@hotmail.com> wrote in message
news:U493m.22480$S16.13826@newsfe23.iad...
Apparently someone at Microsoft decided that a ReleaseSemaphore with
a count of zero is illegal, so it can't be used to get the count
value as a "previous" value. Is there a way to get the semaphore
count without affecting the signaling of the semaphore?
ReleaseSemaphore returns the "previous count" as an optional output
parameter.
Why would you use a semaphore to count messages? The Interlocked API
would be much better for anything like that.
Again not the point. ReleaseSemaphore already returns the "previous count"
as an optional output parameter, so why make a release count of zero call
illegal instead of allowing it to return the current count?
A semaphore used to represent the count of messages in a fifo message
queue, combined with a mutex for ownership of that queue during updates,
can take advantage of WaitForMultipleObjects(), which eliminates priority
and multi-event conflicts. The combination is idea for inter-thread
fifo messaging.
Or you could just use MsgWaitForMultipleObjects and a real message to wake
the thread... with Interlocked* to maintain a count of queued messages if
you want.
But unless I'm much mistaken, semaphores start at N and count down, while
message counts start at 0 and count up, and the bound is potentially very
high.
Semaphores are designed for things like sharing a pool of M database
connections between N threads.
Below is a link to example multi-threaded code for a file copy. I use it
as a template for multi-threaded apps. One thread reads from a source
file, the other thread writes to a destination file, and each thread has
an input fifo queue of messages with pointers to buffers and buffer size:
http://jeffareid.net/misc/mtcopy.zip
There is some setup overhead, but look how simple the code in
ThreadFile0() and ThreadFile1() is.
Haven't looked at your example yet because it requires a download, etc. But
from the description it sounds like you could do very well with just an
event.
In such cases I wouldn't even use multiple threads. You don't have multiple
computations that need to run at once. I/O completion routines are the way
to go, but OVERLAPPED I/O and events work pretty well too. Or IOCP, which
I've never bothered to figure out because completion routines are so
straightforward.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4212 (20090703) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com