Feeder thread semaphore sync policy choice
Feeder thread semaphore sync policy choice
- Subject: Feeder thread semaphore sync policy choice
- From: Kurt Bigler <email@hidden>
- Date: Thu, 3 Apr 2003 15:31:22 -0800
I have feeder threads working in my synthesis app. Since the IOProc
now returns very quickly now, I no longer get overload notifications
from the HAL. However my feeder thread can still take too long to
execute, and when this happens it means my feeder thread's semaphore
will get signaled while it is already executing, whereas "normally" the
thread is asleep waiting on the semaphore, and the signal wakes it up
to start doing synthesis for the next buffer. I want to make sure I
understand what is supposed to happen in the situation where the thread
is running when the semaphore is signalled.
I can not understand from the documentation the difference between
SYNC_POLICY_FIFO and SYNC_POLICY_PREPOST. In fact by my reading, two
different pieces of documentation appear to give opposite explanations
of what SYNC_POLICY_PREPOST does.
The online doc for semaphore_create
http://developer.apple.com/techpubs/macosx/Darwin/General/
KernelProgramming/synchronization/chapter_15_section_2.html
states the following
The prepost policy causes the semaphore_signal function to not
increment the counter if no threads are waiting on the queue. This
policy is needed for creating condition variables (where a thread is
expected to always wait until signalled). See the section Wait Queues
and Wait Primitives for more information.
The "Wait Queues and Wait Primitives" link takes you to this page
http://developer.apple.com/techpubs/macosx/Darwin/General/
KernelProgramming/scheduler/chapter_8_section_11.html
which states
The wait_queue_alloc and wait_queue_init functions take a policy
parameter, which can be one of the following:
SYNC_POLICY_FIFO first-in, first-out
SYNC_POLICY_FIXED_PRIORITY policy based on thread priority
SYNC_POLICY_PREPOST keep track of number of wakeups where no thread
was waiting and allow threads to immediately continue executing
without waiting until that count reaches zero. This is frequently used
when implementing semaphores.
It sounds to me like the first page is saying that SYNC_POLICY_PREPOST
causes the signal to be ignored if no threads are waiting on the
semaphore, which in my case includes the case where the thread is
already executing. So it sounds like SYNC_POLICY_PREPOST will cause
"extra" signals to be ignored.
But the second page seems to say something else, although I suspect it
is badly worded and means to say that SYNC_POLICY_PREPOST causes
signals to be counted when no thread is waiting.
Does this appear to anyone else to be a contradiction?
I need to understand this clearly before I can correctly design my
buffering scheme to handle the overload-like condition, which now
occurs in my feeder thread rather than on the IOProc thread. I would
like to be able to know that the overload has occurred just from how
the semaphore behaves, if that is possible. That is I would like to
know when a signal has occurred when I was NOT yet waiting on the
semaphore. So far I have just relied on the wakeup features and have
not looked at the value of the semaphore. I suspect I need to look at
the value of the semaphore before waiting on it, to find out whether a
signal has already occurred.
I have never used semaphores before, and actually can not seem to find
in the documentation how to get the semaphore's current value.
Thanks for any help.
-Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.