From: support@qdeck.com (Technical Support)
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Organization: Quarterdeck Office Systems, Santa Monica CA
Date: Tue, 13 Oct 1992 20:03:09 GMT

In article <1992Oct12.132904.5770@gw.wmich.edu> x90wardell@gw.wmich.edu writes:
>In article <7545@lib.tmc.edu>, jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:
>> In article <1992Oct10.223900.5743@gw.wmich.edu> x90wardell@gw.wmich.edu writes:
>> [about DV, being preemptive or non-preemptive]
>>>	This is incorrect, Desqview aware programs alone are capable of
>>>telling DV that it doesn't need time but the processor still switches
>>>to it and has to be told this.  DV is cooperative not preemptive, it
>>>is just a lot better at it than Windows and has the ability of acting
>>>almost preemptive which windows programs parently do not do.
>> 
>> Sorry. DV will multitask programs that know nothing about DV. I know, because
>> I do it all day. Under a cooperative multitasker (such as Windows), the
>> applications program must explicitly tell the multitasker to switch processes
>> while the program isn't doing I/O if it wants to give up control of the
>> processor and let something else run for a bit. DV will switch away from such
>> a task, whether or not the task has told it to...this is called "preemption".
>> This is what makes preemptive multitasking such a Good Thing: even poorly
>> written programs will still be multitasked, and this can be achieved
>> transparently.
>> 
>> (This is straying from comp.os.os2.advocacy; DV-only posts should go to
>> comp.os.msdos.desqview. Please pay attention to the Newsgroups: line if
>> following up.)
>> -- 
>> Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
>
>
>	I think we are looking at thigns differently.  OS/2 multitasks
>by having the OS decide when another task gets processor time.  For
>example, if an OS/2 program is just sitting there idle, it gets no
>processor time.  With Desqview, it cycles thru the programs over and
>over.  

I'm sorry, that's incorrect. If a program is idle in DESQview (for
example waiting for a key), it recieves _no_ processor time until there
is work for it to do. In fact, there is some pretty sophisticated code
in there to detect busy-wait loops, and suspend the program until there
is something for it to do. (This is how TAME works, although I must
admit TAME does a better job...)

>	For example, if you have 3 programs, 2 of which are actually
>doing something and one of them is a word processor that is currently
>doing nothing here are how the two enviornments handle it:
> We have 15 clock cycles available:
>
>Terminal program: Gets enough of the processor to keep it going well
>Virus Scanner:	Gets just enough processor to keep it going well
>Word Processor: doesn't get anything.
>In numbers, we could say that teh Terminal program gets say 9 clock
>cycles, the virus scanner 6 cycles and the word processor 0.
>
>Under Desqview, each app would get 5 clock cycles.
>(These are back ground tasks by the way).

Actually, since the teminal is waiting for incoming characters and
keyboard input, and the word processor is waiting for the keyboard,
only the virus scanner would be getting ticks. When a key is available
(or a character from the com port for the terminal), the appropriate
interrupt is allowed to take place, and the suspended application is
then allowed to resume it's time-slice to service the input. 

>DV handls multitasking of DOS in the SAME mannger os Windows 3.1 (except
>that Windows gives them a bit more protection).  
>
>Windows programs themselves must explicitly give up the processor.

DESQview is a pre-emptive multitasker. Windows is non-preemptive. Both
will suspend an application when it says it's ok (by actively doing so,
or by implicitly doing so with a keyboard read or somesuch), but DESQview
(and OS/2) will also interrupt an application that is doing work when it's
timeslice is done, and pass control to the next task. This will allow you
to let two not-terribly-well-behaved applications multitask, even if they
don't want to give up control. (If an application really has a good
reason to keep control, it can request a critical region from the DESQview
kernel, but most apps don't). In Windows, you can pretty easily write
an application that hogs the cpu time and makes all the other apps grind
to a screeching halt (I have! :-) ). In DESQview, you have to be _trying_
to kill the other apps...

-- 
Tom Bortels - Quarterdeck Office Systems - Internet Support 
    For questions or Technical Support, write to support@qdeck.com