Re: INFO-ADA Digest V88 #47

[barmar@think.COM (Barry Margolin)]

In article <415@zap.UUCP> fortin@zap.UUCP (0000-Denis Fortin) writes:
>Well, I agree that non-preemptive prioritized task scheduling makes
>sense for some applications.  But in order for it to work, a task has to
>be able to explicitly return the control to the "scheduler" when it has
>expended its time slice. 

In a non-preemptive environment, there wouldn't be any notion of "time
slice".  A task returns control to the scheduler any time it executes
a DELAY, ACCEPT, SELECT, or INITIATE statement, or when it calls a
task entry.

In this case, the purpose of task priorities is not to cause
low-priority tasks to be suspended immediately, but to guide the
choice of a new task to run when a task intentionally gives up the
processor.

If the tasks do a good deal of asynchronous I/O, they will give up the
processor frequently while waiting for input or for an output buffer
to empty.  So you can get something that approximates preemptive
scheduling.  On Multics, we have software that implements
non-preemptive prioritized multitasking in a process, using precisely
this scheme, being used for network servers, so that one process can
handle all incoming mail simultaneously; when one task goes blocked
waiting for the text of a message another task can deliver its
message.  There's a controller task with high priority that waits for
commands from the system operator; if a command is sent, it will
always run as soon as one of the server tasks goes blocked for network
input.

(As an aside, it is theoretically possible to do pre-emptive
scheduling with the above software, by using timer-driven process
interrupts (similar to Unix signals), and having the timer interrupt
handler invoke the multi-tasking scheduler, but I don't think anyone
has actually tried this.)

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar