Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!neon!torrie From: torrie@cs.stanford.edu (Evan J Torrie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?) Message-ID: <1991Jan27.014242.2863@Neon.Stanford.EDU> Date: 27 Jan 91 01:42:42 GMT References: <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG> <1991Jan25.073516.29644@Neon.Stanford.EDU> <1991Jan26.035750.11786@NCoast.ORG> Sender: torrie@Neon.Stanford.EDU (Evan James Torrie) Organization: Computer Science Department, Stanford University Lines: 104 davewt@NCoast.ORG (David Wright) writes:{ >In article <1991Jan25.073516.29644@Neon.Stanford.EDU> torrie@cs.stanford.edu (Evan J Torrie) writes: >> 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. It has been pointed out to me (in email) that the Amiga does not age tasks. This, I guess, can be looked on as either an advantage or a disadvantage, depending on what sort of workload you have. It certainly explains why the Amiga is not Unix. Anyway, my original point was that instead of "running the others" at a lesser priority (therefore, having to decide BEFORE you start your tasks), or changing their priorities (probably not a particularly convenient thing to do everytime you switch programs), why not build such dynamic priority changing into the OS? >> 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. But it IS the OS's [duty|right|job] to be as transparent to the user as possible. If the OS causes my interaction with the computer to be difficult (because of slow response), then it's interfering with what I want to do (remember, this is restricted to a single user system) Perhaps we should take a vote: How many of you would prefer the application you're interacting with in the foreground to be jerky, in return for your background ray tracer or compile getting a few extra timeslices? How many would prefer the application to be smoother, in return for stealing some timeslices from your background tasks? >> 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. Yes, but it's also why Unix is a multiuser OS, unlike the Amiga (virtual memory is also a kicker for real-time systems). >> 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. Doesn't this provide some wonderful opportunities for "nuisance type" programs, which set themselves up to run at a priority of say 10, and then go into a compute intensive loop? Even if I run a raytracer at priority -1, and then another compute bound task, (say calculating Pi at priority 0), then the raytracer will starve... To a person coming from a Unix background, this is not attractive (in fact, one might be tempted to not even call it "true" multitasking [ducking for cover :-)]). > 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). This is silly. There is always some point at which the programmer has to make a decision about how to design the program, and they do that by [analysing|studing] what users want. And I'd vouch that if you ask users, they'd want fast response vs slow response. >> 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. Yes, but that is the hard part :-). Their problem was not with the mechanics of syncronisation, it was with the logic. It's a simple fact of life that multi-threaded applications are harder to write/debug than single threaded apps. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."