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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.