🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----

In article <id.W_QM1.5N3@nmti.com>, Peter da Silva <peter@nmti.com> wrote:

>The overhead has to be paid one way or the other, whether it's by explict
>delay calls in the application or clock interrupts.

as i wrote elsewhere, neither of these is _required_.  you don't have
to require releases or have clock interrupts.  you only need this if
you are interested in keeping average wait time low.  if this is not a
design goal, you can dispense with this.

>For the job to enter the run queue something must have preempted the job
>currently running.

on at least one super i've seen the run queue is managed entirely by
the front-end processor, which has transfer access to the super's
memory.  so the front-end can load the entire job, then order the
super to suspend the running job and (re)start the new job.  even
swapping can be done on such systems by the front end system.  of
course, in this case the super is really a slave coprocessor to the
front-end. :)

>What this is is "realtime scheduling". Scheduling policy
>is a separate issue from the class of multitasking.

some scheduling policies make no sense without preemption, though, and
i tend to think of the choice of whether or not to preempt as part of
the determination of scheduling policy.

>For example, Polyforth uses cooperative multitasking but realtime
>scheduling, while the Amiga uses preemptive multitasking and realtime
>scheduling, and Windows uses cooperative multitasking and fair-share
>scheduling, and UNIX traditionally uses preemptive multitasking and
>fair-share scheduling.

an VMS uses a fair-share algorithm for processes with priority below
16, and a real-time algorithm for processes with priority at or above
16.  realtime processes (16+) cannot be preempted by anything except a
process of higher priority, whereas timesharing processes (<16) are
scheduled in a multi-level feedback queue with round-robin at each
level.  timeshare processes are temporarily promoted to a higher
priority if they haven't had a quantum for a while (i wish amigados
did this).  UNIX does this, and also demotes processes which have had
a larger share of CPU than average.

>Even on my Amiga the "preemption overhead" is too small to measure.

but it is there. :)

>And since a user interface is a real-time problem, the best way of
>doing this is to provide a preemptive real-time scheduler, like the
>Amigas, which provides *excellent* user responsiveness even on a 512K
>16-bit machine running at 7.14 MHz.

agreed; i rarely have problems with my amiga, and since i have a popup
task manager running at priority 5, i can usually fix any problems
reasonably quickly.  sometimes when i'm running ftp the amount of time
spent in ppp.device or the tcp stack (at priority 5) can slow down
the system somewhat, but since input.device is priority 20, the mouse
and keyboard remain alert. :)

>> i guess this all goes to prove that "those who do not learn from
>> history are doomed to repeat it."
>
>No kidding. Ironic, eh?

what really galls me is that all the droids screaming about how
microsoft, intel, etc. are making all these great breakthroughs, when
they are actually doing nothing of the sort...  (well, intel is
reaching new heights in transistor packing, but not in processor
architecture)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMDz30BbgfSHT/piVAQEh+gP+M0XIDKux4/IjcijNvDMxutbEEXsoIYQo
tKZEoWX3bDwUG8hSs6dMpjuru+uQyK7aCuYvgudsYhho/G1EH0kF+qaEmQGD/+Rn
sI9yX/xvq4GVAnPB+5p+ZcSF3S7mzA2pzsffNwvOFeO2WTh1mDtQKwv605U9RzLB
DIzm/lyMDro=
=erep
-----END PGP SIGNATURE-----