Subject: Re: Hard realtime: Directions?
To: SODA Noriyuki <firstname.lastname@example.org>
From: Oliver.Korpilla@gmx.de <Oliver.Korpilla@gmx.de>
Date: 04/12/2005 09:29:12
SODA Noriyuki wrote:
> For "hard realtime" purpose, I think current interrupt-based model is
> best at least while predictable future.
> Unix-like kernel is too complicated and it's really too hard to
> identify longest code path until a realtime process gets scheduled.
> Interrupt based model is far easier to see the worst case, and
> I believe this is the only doable way for some time, if you really
> want hard realtime application.
> Linux kernel is better than NetBSD about fine-grained locking,
> but it's still far far away from hard readtime process scheduling.
> If you only need soft realtime, it's different, of course.
What do you think is meant with:
"We need real-time scheduling support, POSIX real-time extensions, and
thread-safe libraries. There is an increasing number of applications
related to video, voice, and control that need hard real-time support.
We can start by bullet-proofing our thread support and finishing the
re-entrancy issues with our libraries, then continue by evaluating
real-time scheduling and making subsystems of our kernel able to use
From: [Also available at
http://www.netbsd.org/Foundation/reports/2004.html] Report of the 2004
Annual NetBSD Group Meeting
Does any of this sound reasonable? It sounds mostly out of reach at the
time, don't you think. One could improve on the scheduler, or imnplement
POSIX real-time stuff like "realtime" priorities - but it would just be
a facade with not much to back it up, don't you think?
At least it sound like a long-long-long-term goal! ;)
With kind regards,