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: Quinn <email@hidden>
- Date: Mon, 2 Feb 2004 14:55:27 +0000
At 17:19 +0100 30/1/04, Mario Kleiner wrote:
So, am i right that the kernel_funnel has this effect on
all BSD syscalls, even on uniprocessor machines?
Yes.
Does this mean, that the kernel funnel is automatically
released if a thread sleeps in the kernel,
Yes. See the routine thread_block_reason in the following file.
<
http://www.opensource.apple.com/darwinsource/Current/xnu-517.3.7/osfmk/kern/sched_prim.c>
[This link requires an APSL <
http://www.opensource.apple.com/apsl/> account.]
but that it is
not released, if a thread gets preempted by a realtime
thread -- which would cause the realtime thread to get
delayed/blocked on the lock, as soon as it does a BSD
syscall -- basically some kind of priority inversion?
Yes.
Let me just say on behalf of Apple that we recognise that funnels are
bad. We're actively working to eliminate them and introduce finer
grained locking to the BSD portions of the kernel. However, with
current versions of Mac OS X, they are unavoidable.
That would make perfect sense to me, but why doesn't the
same thing happen to the gettimeofday() syscall that i use
for timing and the usleep() when it gets back from sleep?
My guess (didn't have time to check) is that these routines are
implemented on top of Mach primitives, not BSD. Non-BSD syscalls
don't need to take any funnels.
Is there a way to avoid this, e.g. by only using Apples
Frameworks or Mach API's instead of Posix stuff?
Virtually all frameworks use BSD at some point (you can access the
file system or the network without it), so you can't draw the general
conclusion that Apple frameworks won't end up blocking on a funnel.
However, there are some frameworks that are safe. For example, all
of Mach and all of I/O Kit don't need the funnel.
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.
And a last question: Is there an equivalent to mlockall()
to prevent paging for a realtime app?
My stock answer to this question is that, if the system is short
enough on memory that it's paging out parts of your app that you're
touching at realtime, things are sufficiently messed up that the
wiring wouldn't have helped. However, this appropriateness of this
answer depends on what the negative effect of missing your realtime
goal is. For example, glitching audio is not too bad on the overall
scale of things, but failing to lower the rods on your nuclear
reactor is bad (sufficiently bad that you shouldn't be using Mac OS X
to control it).
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
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.