Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!ncoast!davewt
From: davewt@NCoast.ORG (David Wright)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?)
Message-ID: <1991Jan26.035750.11786@NCoast.ORG>
Date: 26 Jan 91 03:57:50 GMT
References: <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG> <1991Jan25.073516.29644@Neon.Stanford.EDU>
Organization: North Coast Public Access Un*x (ncoast)
Lines: 100

In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes:
>  Hey!  We can do this on the Mac too by NOT setting the "Can
>Background" bit!!  :-)
	But the difference is that on the Amiga programs that don't spawn an
input task get along with other programs just fine. It is the exception, not
the rule for programs to spawn another input task, and is certainly not
required for simple applications.
	One of the best examples I have seen of the Amiga's superiority
(although I am of course biased on two counts) is the graphic front end for
Amiga Empire. Here you have a program that:
	a) Shares the same Empire library as all other clients (when run on
		the local machine), saving tons of memroy.
	b) Uses ARexx to extend the Empire game itself by allowing you to
		write macros for things like navigating a ship around the
		world automatically. And the ARexx macros are also
		executed by another task, so you don't have to wait for them
		to finish.
	c) Spawns at least one other task which allows the user to move around
		the map while the Empire game is doing something else, and
		click on sectors to get a census report on the sectors while
		Empire is doing something else.
	d) Spawns even more tasks (at a user defineable "delta" priority) that
		will tell you the best route between two point on the world,
		taking into account mobility costs, mined ocean sectors, etc.
None of these require the user to wait for any of the other actions to
complete before doing something else.
>  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.
	The Amiga method WILL give you the best response. If you want the
current program to give you the best response, run the others (or change
their priority to) a lesser priority than your current program, and it
will get all the CPU cycles it requires.
>  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.
	You read the rest of my message, you know why. The point is that it
is not the OS's [duty|right|job] to determine what the user wants run
the fastest. The computers job is to do what the user wants, not the other
way around, a point Mac users tend to overlook.
>  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].  
	Not at all. If I decide a user is wasting too much time, I SHOULD
be able to cut his CPU cycles to 0 if I choose. Most Unix systems have
a much more complicated scheduler which prevents a task from completely
going without CPU cycles, which is why Unix is not a real-time OS. You can't
be garaunteed a task will execute at an exact time becuase you can't be sure
that some other program, even a low-level one, won't become so "old" that
the OS decidedes it should run. But remember, just because you run something
at a lower level doesn't mean it won't get to run. As we both agree most tasks
do a lot of I/O, and are waiting for user or disk interaction.
>  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].
	The Amiga scheduler provides this, and more. In fact, if you so
decided, you could even put the foreground task higher than many OS
functions, though you are discouraged from doing so. If you choose this, you
could always either run the foreground task higher than normal a point or two,
or run your other tasks at a lower priority than normal a point or two, and
in both cases the foreground task would get all the CPU cycles it needed,
when it needed them most, and would still let everything else run at almost
full speed most of the time.
>  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.
	Not to mention that the program is now being rude by assuming it knows
what the user wants. This is Mac thinking creeping in (the user is too stupid
to know what he wants, and me being a smart programmer will force him to live
with my "better" method for his own good).
>  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.
	This is due to OS/2. On the Amiga it is no more difficult to write
multi-threaded code than it is to write seperate programs, and communication
is identical for keypresses or task-task communication (at the IDCMP
level, which many (most?) applications that support the mouse for more than
just menu selections already use).
>  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??
	Nope. Windows bites, is a huge kludge, and has a rediculously
complex, confusing, and contradictory API.
>  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).
	They don't have to. Each task (even those an application spins
off) can run at any priority they choose. Most programmers would
probobly run the tasks 1 level below the main program.



				Dave