Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!ai-lab!life!burley From: burley@geech.ai.mit.edu (Craig Burley) Newsgroups: comp.sys.amiga.programmer Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: Date: 10 Jan 91 16:16:57 GMT References: <17210@cbmvax.commodore. <1991Jan10.130741.11570@ux1.cso.uiuc.edu> Sender: news@ai.mit.edu Followup-To: comp.sys.amiga.programmer Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139 (617) 253-8568 Lines: 99 In-reply-to: lrg7030@uxa.cso.uiuc.edu's message of 10 Jan 91 13:07:41 GMT In article <1991Jan10.130741.11570@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <17289@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > > In article mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > >Then again, I'll could decide that "true" multitasking means "no task > >can ever be completely blocked out, unless the user specifically > >allows it to happen by tagging the blocked task". That makes a lot > >more sense to me than just not allowing low priority tasks to starve > >higher priority ones. But then the Amiga doesn't have "true" > >multitasking. > > While not every multitasking OS tries to get close to realtime response, > your restriction is nothing you'd expect to find in the average > multitasking system, realtime or not. > > I disagree - every multitasking OS I've worked with (sans AmigaDOS) > either met that restriction, or met it if you never used the real-time > facilities. They all "aged" tasks so that a low-priority CPU-bound > task would get some cycles, even in the presence of many high-priority > cpu-bound tasks. > While what you consider to be multitasking > depends on definition, a wacky restriction designed to exclude mainly the > Amiga OS is silly, and you know it. > > Yup, I know it. To me, it looks like "true multitasking" is defined to > exclude multifinder and similar hacks. I think that's silly. I agree with both of you :-) I'm confused -- is the issue that AmigaDOS' scheduling algorithm allows low-priority tasks to be starved when higher-priority tasks stay eligible? That, to me, has nothing to do with the definition of "true multitasking" -- it is purely a scheduling issue, albeit perhaps an important one in that it might be wrong for a given system or way a system is used. True multitasking, as I believe it is defined, means preemptive scheduling. That is a hard thing to introduce to an operating system with a large installed base including 3rd-party applications. Multifinder is not true multitasking, period. It is cooperative multitasking. Multifinder was doable without a lot of work because the original Mac OS had the concept of cooperative multitasking designed pretty much from the beginning, unlike, say, MS-DOS. However, going from cooperative multitasking to true (preemptive) multitasking is really hard, because suddenly things need to be "locked" against effectively simultaneous access by other tasks, when access to those things used to be effectively locked simply by the owning task not "cooperatively" giving up control until it finished using those resources. Further, applications written under a cooperative or non multitasking OS are likely to not take into consideration possibilities that, for example, files can appear and disappear, directories change names, and so on, while the apps are running. This sort of thing isn't usually too bad for ordinary apps like word processors, perhaps, but for system utilities, it can result in flaky software, at best. Given a system that already has true multitasking, like AmigaDOS, but has a less-than-ideal (or perhaps simply insufficiently flexible) scheduler, it is much easier for the OS developers to enhance the scheduler without affecting existing software. There are still pitfalls, to be sure -- PRIMOS, for example, had an annoying tendency to give a single lower-priority user more CPU time than a higher-priority user because there were many hi-pri users and it tried to divvy up time among the levels somewhat equitably; and things get pretty complicated when processes are interacting via the file system or shared memory and depend on each other, yet eat up resources while waiting for each other (a deadly embrace of sorts) -- but it is a fairly trivial issue compared to true (preemptive) vs. cooperative multitasking. In summary, I don't think it is at ALL silly to define true multitasking to exclude Multifinder, and I doubt that even Apple Marketing would disagree -- and I do agree it IS silly to claim that true multitasking includes meeting any particular set of requirements for task scheduling, especially since "priority levels" are used to mean so many different things in different situations. Some might well argue that if they give one process, "HI", high priority and another, "LO", low priority, any scheduler that wasted time running LO when HI still wanted to run is wrong. It depends on what you mean -- "Run HI, but any time it can't run for some reason, LO is a useful background task to run, but not critical", or "HI is most important, but LO is important also, so run HI a lot but run LO occasionally" -- the latter interpretation is certainly more vague, hence harder to get "right" for any particular situation. Admittedly it is probably more typical. Please note I don't define single-tasking, cooperative multitasking, or true multitasking as GOOD or BAD. They all have their advantages and disadvantages, and I have done lots of useful work in all three environments (the bulk under true multitasking) and had problems with all three. The goodness and badness is no more etched in stone than that of deciding whether to stay single, get married and have no children, get married and have two children, or become a day care worker (talk about true multitasking! :-). -- James Craig Burley, Software Craftsperson burley@ai.mit.edu