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: Wed, 4 Feb 2004 00:10:25 +0000
At 20:46 +0100 3/2/04, Mario Kleiner wrote:
Ah ja, needs to be on uniprocessor as well, because of the
preemptible kernel functions, which pose the same requirements as
really parallel (==smp) threads...
Right. We also need it because I/O Kit executes most 'interrupt'
code on a workloop thread. These threads call up into BSD for things
like disk I/O completion and network packet delivery. They must
acquire the appropriate funnel on the way up to keep BSD data
structures consistent.
It's worth noting that the splxxx routines (eg splnet) are NOPs on
Mac OS X. [Actually, they do some helpful debugging checks but no
actual work.] This is fine because all BSD code runs under a funnel
and all interrupt delivery is done by I/O Kit threads that acquire
the funnel before calling up into BSD.
There's a very short (and information dense) section of Technote 2028
that explains this.
<
http://developer.apple.com/technotes/tn/tn2028.html#MacOSXKernelThreading>
But as introducing fine grained locking in an existing kernel is
quite a time consuming and incremental endeavour, we probably
shouldn't expect this to be completed in the near future? Can i
assume that it will take rather a couple of months or years instead
of a couple of weeks or months?
We stated at WWDC 2003 that finer grain locking will be shipped as
part of a post-Panther major OS release. At this time we've made no
public schedule commitment, so I can't really comment.
What about things like OpenGL, collecting keyboard responses or
mouse button presses? Do the frameworks use Unix device files for
communication with the device drivers (-> ioctls/read/write/mmap ->
BSD calls -> block on funnel) or do they use the Mach-API? The main
concern is not file i/o but querying the mouse and keyboard for user
responses and OpenGL graphics output with well controlled timing,
see below for reason.
Most user space driver access on Mac OS X is done through obvious BSD
API (networking and file system) or via the I/O Kit "user client"
mechanism. See "IMOSX: Accessing Hardware From Applications" for
information about this.
<
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/AccessingHardware/index.html>
However, my concern is that the frameworks might end up hitting BSD
for silly reasons. For example, even something as trivial as getpid
takes the kernel funnel (the first time you call it; the response is
cached in user space). Frameworks, in general, are complex things,
and it's very hard to predict how they behave in this respect. Worse
yet, even if they do happen to avoid funnels in the current
implementation, that's not part of their documented API and there's
no guarantee that they'll maintain this behaviour in the future.
* * *
I didn't have time to read and respond to the rest of your post
tonight. I'll try to get to it tomorrow.
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.