Re: Is there a way to get the current semaphore count?
"jeffareid" <jeffareid@hotmail.com> wrote in message
news:dSo3m.3537$8P7.1854@newsfe21.iad...
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.
I assume you mean event. I don't recall a "message object". From VS help:
The WaitForSingleObject function can wait for the following objects:
Event, Mutex, Semaphore, Process, Thread
No, I mean message. That's what the Msg in MsgWaitForMultipleObjects means.
Don't know why you substituted WaitForSingleObject.
See the help on MsgWaitForMultipleObjects, PostMessage, PostThreadMessage
for more details.
Semaphores already do the job I want. Coding without using the semaphores
Except for the part about having an operation to read the current count.
Where does your algorithm care about the count that it isn't already
interacting with the semaphore? Or does AcquireSemaphore not return the
count the way ReleaseSemaphore does? Oh, there is no AcquireSemaphore,
that's why you're focused on WaitForSingleObject, although all the *WaitFor*
functions work equally well.
May I suggest using InterlockedExchange to store the queue count in a shared
variable after the producer enqueues an item (possible only if the queue
exceed a threshold of interest)? Then the consumer can use
InterlockedExchange as well to atomically swap the count with zero, or
InterlockedDecrement, etc, and do whatever needs to be done based on the
count. That should be quite a bit more efficient than release and acquire.
But I just don't see what's wrong with one event and one shared count
variable if you need to manipulate the count yourself. Do you have multiple
consumers?
would require I toggle event flags based on message queue count to
implement
the equivalent. Using a OS built in feature such as semaphore results in
cleaner code.
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.
Semaphores start off with the count the caller specifies. In my example
below I start off with a count of zero. The caller also specifies the max
count. Look at the simple example code I created to see how semaphores
can be used for messaging via link list fifo.
http://jeffareid.net/misc/mtcopy.zip
There is some setup overhead, but look how simple the code in
ThreadFile0() and ThreadFile1() is.
Still this doesn't explain why a ReleaseSemaphore() with a count of
zero is illegal, when it does have a valid purpose, to get the
current count via the "previous count" output parameter.
Normally the count value doesn't need to be known unless your application
behaves differently based on depth (count) of message queues.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4219 (20090705) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4219 (20090705) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com