Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!ncsuvx!news From: kdarling@hobbes.ncsu.edu (Kevin Darling) Newsgroups: comp.sys.amiga Subject: Re: Multitasking at home (Was Reality check: ....) Message-ID: <1990Dec28.084935.28614@ncsuvx.ncsu.edu> Date: 28 Dec 90 08:49:35 GMT References: <186ab528.ARN08a6@easy.hiam> <186abe5f.ARN08a9@easy.hiam> <1990Dec27.164630.10864@ncsuvx.ncsu.edu> <1990Dec28.000727.24394@zorch.SF-Bay.ORG> Sender: news@ncsuvx.ncsu.edu (USENET News System) Organization: NCSU Computing Center Lines: 98 In <1990Dec28.000727.24394@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > Kevin put lots of disclaimers at the bottom of his article to get him > off the hook on this, but I still want to answer one part. Yeah, I was afraid the hook was still there. I had chopped tons out of the article, and even then decided to email it, but got lazy instead at the last moment :-). Okay, let me see: > [general comments about aging scheduling omitted] However, I would > absolutely _hate_ priority aging on the Amiga, or any single user > machine, except perhaps as an option I have to specifically _enable_. Agreed that it's a good idea for kernels have lots of options, and even better if they're settable by the user at any time. Choice is good. > [example of terminal program running at slightly higher priority] > _But_, when I turn on the kermit session for which I default the > terminal task priority to 3 in my startup script, I _desperately_ need > that priority to stay high, [...] It does. You're thinking (I think) that when the other processes age enough to win a slice, that the term program will suffer. It doesn't, I assure you. The hit on its time is very small for several reasons: the term program is often waiting anyway (another example of fancy scheduling [aging in this case] degenerating into simpler methods); the temporarily aged procs often end up doing I/O and waits; and wakeup of the term program usually inserts it at the front of the ready queue. > [....] I think it is entirely inappropriate to a single user system, > where the user has, and wants to have, complete control over priorities. Yes sir, we differ here. I think that a scheduler where "higher priority" means: a process gets more slices... is more intuitive and gives more control than when it means: Stop normal preemptive multitasking until an OS call (which Waits) is done. > In your example, the user has just done something stupid by setting the > priority of a compute bound job high; that is the exact opposite of > normal practice, and the bad results should be blamed on operator error, > not on inferior multitasking algorithms. But aging gives the user some interesting slack. You can, for instance, run a utility at even higher priority than the term program in order to get quicker output, without too much fear of botching the term program up, as it'll age and get a chance to run, too. More importantly, you can start several compute-bound tasks with different priorities, and ALL run a little bit, instead of in sequential order as under Exec. I mean, if you're going to multitask, then you should _multitask_ ;-). > Just a comment from out in left field, lest anyone start clamoring for > aged priorities without thinking it through. You're right in the part > I omitted, Kevin, I would NOT want the OS/9 method for the Amiga; OS/9 > is, I understand, fairly often used for multiuser systems. That's true. NASA, etc. Frankly, this is one of the reasons OS-9 gets into places Amigans often wish Exec would (but cannot easily). So CBM is going with Unix, which is not exactly a small user's system. Your comments are appreciated and understood, Kent. But, well, maybe it's like.. hmmm. You know how hard it is to explain the benefits of multitasking to people who haven't used it? I think the same applies for aging, and for the multiuser aspect also. Certainly I've met no one so far who's programmed under both Exec and OS9, and who didn't prefer OS9's scheduler. It's stood the test of time for over ten years in many realtime apps. > I hope no one _ever_ creates a deliberately multiuser Amiga; Too late. The A3000UX. A2000 with networking. Okay, okay, jest kidding ;-). > that would be a huge step backwards, even though hacks to make BBSs work > are fine anyway; I just don't want to see the machine go multiuser in > focus; the world of computing is moving away from that idea, for me, > correctly. Omigosh, you mean you agree with _Pournelle_ about "one user, one machine"? Sorry, that was mean :-). Seriously now, the multiuser orientation has beneficial side-effects, especially for the home/biz user. The first one that comes to mind (in the case of OS9) is the automatic file record locking. A commonly given Amiga example is that of "doing something with a downloaded file while downloading yet another". Under OS9, you can dearc/degif/etc a file _while_ it's being downloaded, and both (or several) programs stay in file sync. This probably was mostly meant for multiuser record accesses, but the single user loves it! Plus it's a piece of cake to network multiuser machines. Remote logins are common practice. BBS's are a snap, of course. Protection for files on your hard disk from your kids. It's cheaper to buy a hot 030 machine with a large HD, and just get surplus/cheap-computer terminal setups for the rest of the family (yah, no remote gfx yet, tho that's coming). Long enuf for now... I was trying to avoid running on like this :-). Cuts into my work time (anytime you want to drag me away, please do!) And I'm not after an Exec vs OS9 thingie... but rather to point out that there are Some Neat Things that could be added to Exec. Thx for listening Kent (and all)! - kev