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