From: aml@world.std.com (Andrew M Langmead)
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Organization: The World @ Software Tool & Die
Date: Tue, 13 Oct 1992 16:18:36 GMT

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.  

There are instances where DESQview will suspend a running program until
it has something useful to do. If a program makes a DOS or a BIOS call 
to get a key, it will be suspended until a key is pressed IN THAT WINDOW.
The bit problem with DOS based programs is that many programs, instead of
being written like:

while(!quitting)
{
  nextchar = getkey();
  handlekeypress(nextchar);
}

they are written:

while(!quitting)
{
   if(iskeypress())
   {
     nextchar = getkey();
     handlekeypress(nextchar);
   }
   else
   {
     doidletask() /* update clock in status bar, reflow document, etc. */
   }
}
(Please no flames on indentation, coding style, or how much this can or 
can not resemble and actual program, etc. This is just to set up the 
following text.)

doidletask() probably is a big "if-else if-else" or "select-case" construct
which will change the clock in the title bar IF more than a second has passed
since the last time the clock was updated, will reflow the text of the 
document IF a word is outside of its margins, recalculate formulas IF
a dependant cell has changed, etc. Pick whatevery you want to imagine is in
the idle function.)

The funtion doidletask() probably get called a lot more often than is
necessary. DESQview has no way of knowing how often that part of the code
should be called (it depends on how much stuff the programmer set to do
when nothing else is being done.) The program needs to poll for input because
otherwise the status bar clock would only update when a key is pressed.
(document would reflow around the margins, would recalculate, etc.)
My question about OS/2 is how does it know the DOS based program doesn't
really need to run in this example. (I know the an OS/2 program would
spawn a new task to handle the clock, maybe another one to reflow the
document, etc. My DESQview programs spawn separate tasks for those 
purposes as well, (or call obq_read() to sleep until any type of input
is available.) If it suspends programs when they poll many DOS
programs would not act correctly. (depending on what they needed to get
done in the idle function.) The polling "tamer" programs, for DESQview help
in this instancer because if doidletask() keeps returning very quickly,
(clock does not need to be updated, no recalculation or reflowing necessary,
etc.) they assume that the program is not doing anything important and then
suspends them. If doidletask() takes a long time to execute (so there is a
long time between keyboard polls) then the program must be doing "something"
and it will continue to get execution time.


>	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.

For programs written for OS/2, DESQview, Unix, etc. The terminal program
shouldn't need all that much time, (under OS/2 and Unix, the serial 
communication itself is taken care of by the OS, the programs will be
suspended until their input is in. Under DESQview the interrupt routine
will get called when necessary, and the mainline program should suspend
itself until the ISR wakes it.) A DOS based program running under DESQview
will need to to quite a bit of polling (has the ISR set the ready flag?) This
is harder for a multitasker to deal with because it can't look at the number
of times a system call is executed, it would have to look at the number of
times a memory location is accessed. Does OS/2 do a good job of noticing this
sort of interaction between the ISR looking at its virtualized port and
the mainline program? (In a general purpose telecommunications program, the
test for the ready flag would probably be in the doidletask() area, so
again the "taming" utilities would work.)

Take a look at a program like Brief, or MicroGNUemacs under OS/2, does
the clock change? If so, it must be getting some processor time. I realize
that the clock isn't all that important, and even if the clock only changes
when a keystroke is received, most people wouldn't care. It is only an
obvious example of what might be an idle task for the program. (If a program
does more important things in its idle routine, it will need a higher 
priority in DESQview or OS/2 whether it those idle routines are being
executed or not. (A telecommunications program will need a higher priority
even if it is not online.)

By the way, are you talking about explictly changing the priorities of 
the OS/2 programs? A well written OS/2 text editor would not use up much
processor time even if set for a high priority. (a well written DESQview
program would not either.) If you are talking about setting the priority
low for the text editor, higher on the telecommunations program, then this
is similar to a "Tame" utility for DESQview, skewing the scheduling 
algorithm, based on user preference.


>Under Desqview, each app would get 5 clock cycles.
>(These are back ground tasks by the way).

First thing I want to stress is that this is true only if the programs
are polling, not blocking for input, (A COMMAND.COM will not take up any
time time until the user presses a key) and if DESQview has not been told
to suspend tasks if they poll too much.

This is still describing a pre-emptive system. If you are trying to say
that OS/2 has a BETTER pre-emptive multitasking scheduler, I would agree.
The priority and delta mechinisms give the user and the programmer much
flexibility in program performance. (The DESQview that is in DESQview/X
allows task priorities, as a programmer almost can't wait until I can
access that capability in standard DESQview.)
Keep in mind, people don't choose an OS because of the scheduler.

>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.

Windows in 386 enhanced mode pre-emptively gives time to each virtual machine.
Each DOS program is its own VM, all windows based programs share a VM. If a
windows program is greedy, it will only starve the other windows based 
programs. It is co-operative multitasking the Windows VM and pre-emptively
multitasking the VMs  themselves.
>						-Brad

>=================================
>Brad Wardell  **Happy OS/2 2.0 User**
>Project Director
>Stardock Systems (SDS)
>Western Michigan University
>Western Michigan Universit









-- 
|Andrew Langmead - A frustrated Mac/Unix programmer stuck in an MS-DOS job    |
|Usenet=aml@world.std.com      |S. O'Conner "We Live in a dangerous Age       |
|bix=a.langmead CI$=72411,1560 | To say how you feel is to lay your own grave"|
Newsgroups: comp.os.msdos.desqview