Re: Long latencies in realtime threads when doing BSD syscalls -- Bug or expected behaviour?
Re: Long latencies in realtime threads when doing BSD syscalls -- Bug or expected behaviour?
- Subject: Re: Long latencies in realtime threads when doing BSD syscalls -- Bug or expected behaviour?
- From: Jim Magee <email@hidden>
- Date: Wed, 4 Feb 2004 15:44:28 -0500
On Feb 3, 2004, at 2:46 PM, Mario Kleiner wrote:
Our current -- ugly -- solution is to kill the update()
process during realtime parts of the application. Is there
something better, e.g. the equivalent of SCHED_FIFO
scheduling on other Unices?
The best solution is to avoid doing BSD stuff in your realtime
thread. For example, let's say you're playing an audio file, reading
from disk and playing via Core Audio (which calls you back in a
real-time thread). The best way to do this is to separate the disk
read and audio play into two threads, insert a buffer between the
two, and make the disk thread non-realtime.
If you can explain exactly what your realtime thread does, I can
perhaps offer some alternative suggestions.
Avoiding BSD stuff in this case is difficult: The application is
called Psychtoolbox for MacOS-X (see
http://www.psychtoolbox.org/osx.html ). It is an extension to/on top
of Mathworks Matlab. It is used for programming psychophysical
experiments on human visual perception in Matlab -- basically
presentation of visual stimuli via OpenGL and collection of keyboard
and mouse responses with controlled timing. Its very popular under
vision scientists on the old OS-9 Macs and Windows and they are
porting it to OS-X at the moment.
Note that avoiding BSD calls is not really sufficient anyway. A BSD
funnel is just a special form of Mach mutex (that gets dropped when you
voluntarily sleep), but a mutex just the same. And those are the same
things that Mach uses to guard many of its (and IOKit's) resources. It
may be more likely to conflict with someone holding the BSD funnel
(mutex) than say the Mach port namespace or address space lock for your
process/task, but eventually you will hit that one already locked too.
The point is not to eliminate conflicts, but to "bound" them in
duration. This takes two parts:
The first part falls on all Apple/Darwin kernel developers - and that
is to limit singular lock holds to an acceptable latency value. This
is an ongoing process. And yes, as we are eliminating reliance on the
funnels we are also trying to bound the holds on the new locks that
replace it. But this will be an ongoing effort for some time to come.
And doing things like file I/O operations will likely always fall into
the category of having too high a latency for time critical threads.
The second part is to assure these lock hold latencies don't stay
unbounded because of priority inversions (the lock hold is low priority
- starved of the CPU by a medium priority thread - which means your
high priority thread will never get the lock it needs). We already
have priority inheritance mechanisms in place - with more and better
ones to come in the future (for instance we can't take mutexes out of
their FIFO ordering yet because of of potential starvation issues - but
we are working on remedying that).
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.