On Sep 11, 2006, at 2:12 PM, Shaun Wexler wrote:
On Sep 11, 2006, at 9:42 AM, Jeremy Sagan wrote:
I am trying to optimize thread performance and it almost works
perfectly. What I am trying to do is to signal a high-priority
secondary thread to wakeup and execute as soon as possible when
certain criteria is met on a core-audio thread. I am using
semaphore_signal to signal to the secondary thread. I also am
having the secondary thread sleep only for the appropriate number
of nanoseconds with semaphore_timedwait in an attempt to have
just wake-up on time. The problem I am running into is that the
secondary thread will sleep sometimes for more than 30
milliseconds even after being signaled by the semaphore mechanism.
Is there a way to tell the scheduler to immediately place the
secondary thread at the front of the queue?
I have tried setting real-time priority with
THREAD_TIME_CONSTRAINT_POLICY but it does not seem to make any
difference. In fact it actually works better if I simply set a
high priority using THREAD_PRECEDENCE_POLICY.
kern_return_t semaphore_signal_thread(sempahore_t sem, thread_t
thread);
Ah, another caveat here. This function only works if the thread is
already waiting on the semaphore; NOTE: it does not prepost to the
semaphore (increase the semaphore's "signal" count). If
semaphore_signal_thread returns KERN_SUCCESS, that means the thread
has been made runnable, and it has already begun running if there
was an idle processor available, or it has been queued according to
normal scheduler behavior if all CPU's were busy or it's a UP.
This means that if semaphore_signal_thread returns
KERN_NOT_WAITING, then you will have to set an atomic flag so that
your secondary thread which is either (A) currently running or (B)
not runnable will test the atomic flag to perform its work
immediately instead of waiting on the semaphore, or immediately
call semaphore_signal to prepost, otherwise you'll have to handle
the secondary thread processing in the next IO cycle.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
