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 | 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.