Jukka Marin wrote:

> This would be the best solution for this and other problems.  Some way
> of ensuring that a critical process gets all the CPU it needs - WHEN
> it needs it.  On the Amiga, the scheduler was very simple, and a
> process priority high enough allowed a process to get all the CPU it
> wanted.

...pretty traditional.

> I think I've heard something about real-time support in linux - I don't
> know any details, but maybe NetBSD should have something like that as
> well?

The most useful real time implementation in Linux is the RtLinux stuff.
This effectively runs the linux kernel atop a hard realtime microkernel.
This works very well indeed and provides the guarantees needed to run
something like a softmodem perfectly well. You can communicate with the
realtime kernel from the main kernel through pipes.

OTOH, FreeBSD provides a 'simple' realtime process mechanism (man
rtprio) which allows processes to be launched at 'real time priorities'
(run above all others) and 'idle priorities' (run when no others do). I
think these approaches still fall foul of the bogus tsleep priority
boosting, as an implementation in NetBSD may be likely to do, but I
don't really know enough about these issues in NetBSD to make firm
comments.

I think to really make something like BSD hard-realtime, to support the
EDF/rate-monotinc scheduling, fully reentrant kernel, guaranteed
interrupt latencies etc would pretty much need a rewrite of the core
kernel, elimination of spl() etc. However for good multimedia
performance, all of this isn't needed (although tsleep might still be a
pain).

	Neil

-- 
Neil A. Carson