Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool2.mu.edu!uunet!timbuk!cs.umn.edu!sialis!orbit!pnet51!chucks
From: chucks@pnet51.orb.mn.org (Erik Funkenbusch)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?)
Message-ID: <3931@orbit.cts.com>
Date: 30 Jan 91 00:05:02 GMT
Sender: news@orbit.cts.com
Organization: People-Net [pnet51], Minneapolis, MN.
Lines: 33

dac@prolix.ccadfa.oz.au (Andrew Clayton) writes:
>In article <1991Jan27.221142.20062@ncsuvx.ncsu.edu>, John Vestal 
>
>And in article <1991Jan27.223145.18292@Neon.Stanford.EDU> (Evan J Torrie)
>
>
>You both want the operating system to stick it's nose in, or at least do some
>cogitation on what SORT of task gets timeslices.
>
>No dice.  Going on my knowledge of mainframe schedulers leads me to believe
>that task switching based on what the USER want's to achieve is ALWAYS better
>than any generalised 'guessing' algorithm in the OS.
>
>You prefer the OS to do some thinking for you, but that algorithm has to be
>worked out, and no *generalised* one will meet everyone (or even anyones!)
>personal preferences.

There is a simple solution to this.  All it requires is that everything stays
the same EXCEPT that everytime a quantum expires then that tasks priority is
lowered by 1.  Then when all priorities have been lowered to the lowest tasks
priority they get re-set to their beginning priorities.  this would both Age
tasks, allow for higher priorities to get more cpu time, and prevent task
starvation while interupts could stay the same simply by raising a tasks
priority when it recieves a signal.  This way real-time processing would still
take place, yet tasks would run much better.  just an opinion of course.
> _l _  _   // Andrew Clayton. Canberra, Australia.         I Post  .
>(_](_l(_ \X/  ccadfa.cc.adfa.oz.au!prolix!dac                     . .  I am.                   
>-------- I cannot send or receive email. Not to anyone at all. Not even you.


UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks
ARPA: crash!orbit!pnet51!chucks@nosc.mil
INET: chucks@pnet51.orb.mn.org