Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.realtime
Subject: Re: IEEE Tutorial (Really priority
Message-ID: <129300003@p.cs.uiuc.edu>
Date: 1 Jun 89 16:18:00 GMT
References: <34054@sgi.SGI.COM>
Lines: 30
Nf-ID: #R:sgi.SGI.COM:34054:p.cs.uiuc.edu:129300003:000:1491
Nf-From: p.cs.uiuc.edu!gillies    Jun  1 11:18:00 1989


In article <7252@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
> I find it hard to believe that most existing realtime tools (e.g.
>VRTX, Rex) use priority scheduling.  I'm interested in making the
>GNU kernel able to deal with hard realtime events, such as
>those required for support of high bandwidth, low latency hardware,
>and priority scheduling would make systems that 'seem to work' but
>in which there is no way to engineer them so that they WILL work.

Wait a minute.  What is so wrong with priority scheduling?  Priority
scheduling algorithms can be used to solve any problem that does not
require inserted idle time in the schedule.  All you need to do is
assign the *right* priorities.  Priority (greedy) scheduling is one of
a handful of algorithms fast enough to be incorporated in a real-time
system.

Rate Monotonic Scheduling is an optimal *static* priority scheme (i.e.
no other static scheme can do better).  Are you complaining about
"static" priority scheduling?  Do these real-time systems prevent you
from changing the priorities?

At the moment, there is no panacea in real-time scheduling.  We need
more information on exactly the problems you wish to solve in the GNU
kernel.  In scheduling, there is *no* "general" algorithm to solve all
(or even many of) the problems optimally.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies