Tue, 10 Aug 1999 07:31:14 -0400
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.
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139, USA