At 04:24 PM 8/9/1999 , Harbaugh, John S wrote:
>I'm always curious why someone would choose time-slicing as a dispatching
or scheduling mechanism.  It is a poor-man's  attempt to simulate
parallelism on a single CPU computer.  Most authors (Ben-Ari, Burns &
Wellings, to mention a few) recommend that programs be designed around the
idea of concurrency, the _potential_ for simultaneous execution of multiple
instructions, rather than parallelism, the required use of multiple
processors.  A correct, concurrent Ada program using either preemption or
rendezvous can execute on one or many processors.  Contrast this with a
parallel program that must rely on time slicing to run correctly on a
monoprocessor machine.  Would it not be preferable to use basic language
features rather than rely on non-portable implementation policies?
>

Time slicing is typically used on general-purpose operating systems to
provide some equality among processes on the use of CPU.  If Ada tasks are
implemented using processes, they get time slicing.  I have also seen it
mentioned as used by multilevel secure operating systems to "hide" the
existance of other processes (low-security-level processes are not allowed
to even know of the existance of other processes).

For the embedded world, one could think of a multiple-experiment computer
on some platform.  In that case, multitasking could be used as a poor-man's
multiprogramming system.  Multiple equal priority tasks might want to run
"continuously" for a while, sharing the CPU.  Breaking the tasks into small
pieces is possible, but is a maintenance nightmare.

I certainly agree that there should be a means of turning it off, but that
is typically a flag within the operating system itself; I am surprised by
Tucker's reply that validation people would "frown on" something that has
been in use for so many years.  My assumption here is that the "hard
real-time" folks insisted on the one named dispatching policy not allowing
time slicing, and the soft-real-time people were outvoted.

Roger
Roger Racine
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139, USA
617-258-2489