Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!ames!uhccux!waikato.ac.nz!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?)
Message-ID: <10816.tnews@templar.actrix.gen.nz>
Date: 29 Jan 91 04:19:03 GMT
References: <10620.tnews@templar.actrix.gen.nz> <1991Jan22.215801.4557@Neon.Stanfor 
 <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG><1991Jan25.073516.29644@Neon.Stanford.EDU>
Organization: TAP, NZAmigaUG.
Lines: 74

Quoted from <1991Jan25.073516.29644@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie):
> davewt@NCoast.ORG (David Wright) writes:

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

    Yes it is the best thing to do... look where this discussion is being
    held... :)

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

    Seriously, I don't think it is useful to expect the OS to be able
    to second-guess the user here.

>   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

    So, unlike Unix for the average user, you have access to the
    priorities of every task in the system, to jiggle as you wish.

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

    If you wanted to keep things to the simpler level of cooperative
    multitasking, you could write your program so that it emulated
    the cooperative scheme - run at a high priority to lock out other
    things, but every so often did a little pause to see if anyone
    else wants CPU time.

    You'd have a limited number of customers, but so it goes... :)

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

    Perhaps OS/2 and PM are more complicated than Exec and Intuition.
    That's certainly the impression I've gotten from various journals.

    The mechanics of this sort of thing are straightforward on the
    Amiga. Design problems are a different matter.

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

    A lot of things that Microsoft do arouse wonder... these are the
    keen bunch that gave us AmigaBASIC, remember. The one that (for some
    reason, presumably to keep the program simple) used 24-bit pointers
    despite the clear guidelines against such things.

> 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

    This sort of thing would be best done (IMHO) by designing the
    application to handle it. Suppose that one of the operations the
    user could begin was to scroll the display down (so the user starts
    the scroll, but it's supposed to keep going once they release the
    mouse button - eg: displaying notes as a tune is played, or
    displaying an animation of tectonic plate movement, etc).

> Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***