From: rafetmad@cheshire.oxy.edu (David R. Giller)
Subject: Re: preemptive multi-tasking
Organization: Occidental College, Los Angeles, CA 90041 USA.
Date: Wed, 15 Apr 1992 03:08:52 GMT

In article <1992Apr15.005912.22809@ringer.cs.utsa.edu> mlevis@ringer.cs.utsa.edu (Mike Levis) writes:
>>Just a brief point please. Time sliced multi-tasking IS preemptive. Preemption
>>means a running process in interupted somehow by the operating system. The
>>algorithms it uses to prioritise tasks is irrelevant. OS/2 uses time slicing 
>>the same as every other MT operating system. It interrupts a task (preempts) and
>>allows it to run for a fixed period (time slices) and then preempts again. I 
>>dont know what the confusion over this point is. There was no such thing as
>>co-operative MT before WINDOWS. Preemption is a word that seems to have grown
>>up around OS/2 to distinguish its task managemnt from WINDOWS.
>>
>>DesqView & WINDOWS 3.0 (Enhanced Mode) and pre-emptive systems. I get the 
>>feeling the guy (Bill ?) who started this has realised he blundered his 
>>original post and is now trying to cover this ass with semantics.
>>
>>This is not a flame BTW, just stating the facts.
>
>Time-sliced multi-tasking has NOTHING to do with preemption.
>In fact there are several forms of time-sliced multi-tasking
>(as opposed to Shortest Job First, or First In First Out
>multi-tasking).  Here are the real facts:

[...]

>These are only two methods of multitasking.  What does it have to do
>with pre-emptive multitasking?  NOTHING!!!!   However, a time-sliced
>multitasking algorithm can be made pre-emptive.  This means that a
>running process loses the CPU when its quantum expires, or it accesses
>a device port.  It also means that a running process can be interrupted
>if a process with a higher priority gets placed in the ready queue.
>
>When accessing a device port, the running process can be "blocked" by
>being put in a waiting queue (depending on the implementation). Once the
>device has completed, the first process in the waiting queue
>(for that device) gets put back on the ready queue. At this point,
>a running process may be pre-empted if it has a lower priority than
>the wakened process.

[...]

>Notice that without pre-emption, process 1 uses CPU time even
>thought it is not using the CPU (it is waiting for the comm port).
>Notice that with pre-emption, process 1 does not use CPU time since
>it is in the waiting queue, not ready queue.  Also, process 2 runs
>faster since it gets the CPU to itself!
>
>This is not a flame BTW, just stating the facts.

You are correct about the fact that round-robin and Multi-level Feedback
Queue are not the same.  However, your definition of time-sliced
multitasking is incorrect.  By your definition, ALL multitasking on a
single CPU is time-slicing.  To avoid misunderstanding, I won't use the term
time-sliced multitasking.

You are also incorrect about what pre-emptive means.  The difference
between cooperative and pre-emptive multitasking is that in cooperative
multitasking, the quantum is as long as the application wants it to
be, and the OS is powerless to interrupt (pre-empt) it if something
else needs to be done.  In pre-emptive multitasking, the quantum is of a
system-defined time period.  When the timer runs out on the quantum,
the OS pre-empts the running thread, and starts another one.  In addition,
if a thread of a higher priority becomes ready to run during a quantum
of another thread, it will also be pre-empted in favor of the higher-priority
thread.  Pre-emption has nothing to do with port access, except that
because of the higher control the OS has over the running threads, it
need not even run the application if its hardware access isn't ready
(you did point this out).

What I don't understand is that you say something different below:

>BTW, BIOS uses cooperative multitasking when it uses INT 09 (keyboard)
>and INT 08 (timer update).  This means that the interrupt handler
>keeps control of the CPU until it wants to finish.  Keep in mind that
>interrupts are disabled upon an INT unless the handler uses STI.

No, this isn't cooperative.  This is, to a limited extent, pre-emptive.
The BIOS pre-empts the running process to do hardware access.  Now,
interrupts usually aren't considered any kind of multitasking, even
though they can be jury-rigged to do it (and the timer is on an interrupt,
but it is only used to signal the OS that a pre-emption is in order).
The PRINT command sets up this kind of semi-pre-emptive multitasking to
run its print spooler.

To deal with the term 'time-sliced', it is usually used as a synonym to
pre-emptive, because in pre-emptive multitasking, the OS allocates a
designated (not necessarily fixed) slice of time for the application
to run, and it interrupts the application when its time is up.  It must
maintain a context of registers and stack, because the application
can't know when it is being pre-emptive, and the system can't corrupt
the stack.  In cooperative multitasking, the application knows exactly
when it is going to be pre-emptive, since it usually uses a function
call to yeild the processor.  Registers aren't preserved across function
calls, and the stack can be marked so that it can be easily returned to
its pre-yeild state.

-Dave

-- 
David Giller, Box 134 | Q: How many Oregonians does it take to screw in a light
Occidental College    | bulb?  A: Three.  One to replace the bulb, and two to
1600 Campus Road      | fend off all the Californians trying to share the
Los Angeles, CA 90041 | experience. ---------------------------rafetmad@oxy.edu