Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!agate!shelby!neon!torrie
From: torrie@cs.stanford.edu (Evan J Torrie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Single user OS schedulers (Was Re: How do we change the scheduler?)
Message-ID: <1991Jan25.073516.29644@Neon.Stanford.EDU>
Date: 25 Jan 91 07:35:16 GMT
References: <10620.tnews@templar.actrix.gen.nz> <1991Jan22.215801.4557@Neon.Stanfor <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG>
Sender: torrie@Neon.Stanford.EDU (Evan James Torrie)
Organization: Computer Science Department, Stanford University
Lines: 101

davewt@NCoast.ORG (David Wright) writes:

>In article <1991Jan23.213736.28220@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:

>>  You say some programs do use input-handlers... does this mean they
>>multi-thread themselves, spinning off an input handler task, and then
>>communicate between the main program and the input handler task?

>	If they wish, but that is not normally needed. Most programs on
>any machine are waiting for user input, not running in the background.
>For instance a paint program would have no need to spawn another task
>for input, since it is always waiting. 

  Hey!  We can do this on the Mac too by NOT setting the "Can
Background" bit!!  :-)

>>  Thus, it seems to be possible to buffer up a whole lot of mousedowns
>>on the scroll bar, all received by the input.device task, but the
>>actual code to regenerate the window won't be scheduled...  thus won't
>>you get a jerky, or at least a non-responsive task?

>	Yes, but the user would expect this, if they had a lot of other
>programs running at the same priority.

  A user accustomed to the Amiga scheduling system would expect
this... Does that necessarily mean it is the best thing to do?  I
would prefer a system which allowed me to work as fast as I can on the
program I'm current working on..  i.e. interactive response.

>>  I'm just wondering if you would get better response by having the OS
>>temporarily boosting the priority of an interactive task (e.g. raising
>>the word processor priority to 10 while the user is clicking on the
>>scroll bar in the WP's window)

>	Yes, this would work. But is very rude, and not many programs do
>this. How do you know that the user WANTS the WP to work smoothly?

  Why WOULDN'T the user want the WP to work smoothly??  I really can't
see that someone would PREFER to have their WP jerking around all over
the screen, since it makes the system much more unusable.

>Personally, I run a multi-user game on my computer 100% of the time, in
>the background. 

  Yes, but this raises another issue.  In this case, you are running a
task which is servicing other users... effectively, you want your
scheduler to give good multiuser response [i.e. no starvation].  
  For these cases, Unix-like schedulers (which it seems the Amiga
scheduler is modeled after, judging by the description so far) are
definitely the right choice (after all, a lot of work has been put
into researching the best scheduling systems for MULTI-USER OSes)
  But has anyone considered that practically ALL PCs are single-user
machines.  I don't run tasks for the benefit of other people.  I want
what I'm working (in the foreground) to give me the best response
possible, even though it may starve some of the tasks in the
background [not time-critical ones though such as I/O].
  Has anyone investigated alternative schedulers which take the
concept of "single user OSes" into account? (Just an idle question
directed at the research community).  What differences are there (if
any) in the "best" type of scheduler for single user vs multiuser
systems?
  Perhaps one valid solution is to multithread your application, and
spin off a high priority thread handling user input AND screen
regeneration.  However, this sort of negates the advantage of
preemptive multitasking vs cooperative multitasking, because now you
have increased the complexity of your previously simple application.
  I was involved for a short time with a group writing an OS/2 PM
multithreaded application.  They spent a large amount of their
debugging time trying to remove bugs associated with
synchronisation/communication of their threads.
  Is it any wonder that when Microsoft wrote their version of Excel
for OS/2, they wrote it as a single-threaded task, throwing away all
those nice capabilities of OS/2??

>rare times it occurs. But technically, yes, you could do what you
>want. But why not just run at the same priority all the time? If the
>user wants faster response they can up the WP priority. Since most of the
>time it will be waiting for user input, the other tasks will get plenty
>of time to run in the background, even if the user has the WP running at
>a high priority.

  Time consuming operations though (e.g. importing foreign documents,
formatting for printing, searching and replacing) will still run at
the upped priority in the background (when you really want them to run
at a low priority).
  Perhaps a better example than a WP would be a spreadsheet or
database, which can calculate while you are giving user input.  For
example, you might have a long search on a database, but you also want
to be able to scroll around a list of matching records found so far
(while the search is still going on).
  Or you could go back to my example of a ray tracer where you want to
be able to examine parts of the scene rendered so far.
  In these cases you want the calculation in the background to be at a
low priority... but you want the interactive response when you bring
it to the foreground to be high.

-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
"If it weren't for your gumboots, where would you be?   You'd be in the
hospital, or in-firm-ary..."  F. Dagg