Subject: Re: [linux-audio-dev] Non preemptive driver layer in linux?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Jun 23 2000 - 17:10:33 EEST
>So I assume that the Windows driver layer is also not purely non-preemptive
>"in the sense" that it must also deal with interrupts to execution flow at
>that level as well? I know you can set priority levels on threads in Win32.
>How does this brute force approach to keeping the processors attention in
>Win32 differ from a SCHED_FIFO in linux or at the driver/kernel level in
>Windows?
Win32 is not a truly preemptive operating system, as I understand
it. If a thread decides no to relinquish the processor, it can own it
for quite a long time. the reason Seer did what they did was to get
around this kind of issue - they take charge of the processor from an
interrupt, and hold onto it for as long as they need. thus, if
something else was running as a normal program and didn't relinquish
the processor in time, they are still fine, since they get the
processor on every audio interface interrupt. if they ran as a regular
"user space" thread, they'd be dependent on the regular windows
scheduler, which seems to be a strange mix of cooperative multitasking
and true preemption.
their design also cuts through the layer-upon-layer of API crud
involved in using Windows to talk to an audio interface (which is what
ASIO and EASI and GSIF are all about as well).
On Linux, we already have true preemption, but the default scheduling
class (SCHED_OTHER) doesn't ensure
* rapid return to the processor(s) (e.g. a process may become ready to
run again, but its not known how long it will be until it gets
back on the processor(s) - this would depend on the length of the
run queue, and the operational characteristics of each process
that runs ahead of it - is it i/o bound, or a pure number
cruncher, etc.)
* that a process can own the processor for longer than a time
slice.
SCHED_FIFO does both these things (assuming no other SCHED_FIFO tasks;
if there are, things get more complicated).
>So do you have some inside scoup on them releasing a version of Reality for
>BeOS? :}
None whatsoever.
--p
This archive was generated by hypermail 2b28 : Fri Jun 23 2000 - 17:40:55 EEST