Newsgroups: comp.sys.amiga.programmer Path: utzoo!utgpu!cunews!micor!latour!mcr From: mcr@Latour.Sandelman.OCUnix.On.Ca (Michael Richardson) Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...) Message-ID: <1991Jan12.175908.6479@Latour.Sandelman.OCUnix.On.Ca> Organization: Sandelman Software Works, Debugging Department, Ottawa, ON References: <1991Jan10.130741.11570@ux1.cso.uiuc.edu> Date: Sat, 12 Jan 91 17:59:08 GMT In article burley@geech.ai.mit.edu (Craig Burley) writes: >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. This is indeed a problem that I have frequently had on the Amiga. Often when trying to debug a task that is supposed to run at higher priority than the debugger, or worse, the console.device that the debugger uses... (The problem is really in the debugger, but the issue still arises when low-priority tasks do I/O --- the disk handler should run at the requestors priority) > > 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. Not at all. When I put a compile session at a low priority, I DO expect it to finish. Just a little bit slower. Only tasks such as the input.device and things that interact with ME should pre-empt. (People are real time events too!) > > 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? It is now. >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. The issue of whether MS-DOS/Finder/etc can multitask or not is an issue for comp.sys.amiga.advocacy. (Is this appropriate for .programming?) Is there any chance of having a bit somewhere that will let me desginate a process as 'pre-emptive'? Otherwise, I'd prefer to have a rung on the round-robin system (for equal priority tasks) be assigned to the 'next' lower priority. (Still, if I make something -10, it probably should be run less often than if it were -1, even if there are no other tasks at -10..-1) Does 2.0 make sending DOS packets, and doing asynch dos I/O any easier? Can one abort a DOS request? Thought not... -- :!mcr!: | The postmaster never | - Pay attention only Michael Richardson | resolves twice. | to _MY_ opinions. - HOME: mcr@sandelman.ocunix.on.ca + Small Ottawa nodes contact me Bell: (613) 237-5629 + about joining ocunix.on.ca!