Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!ctnews!mitisft!jay From: jay@mitisft.Convergent.COM (Jay O'Conor) Newsgroups: comp.sys.mac Subject: Re: Multitasking and interactivity issues (long) Keywords: multitasking,interactivity,personal Message-ID: <1364@mitisft.Convergent.COM> Date: 23 Jan 90 18:06:48 GMT References: <1990Jan13.105048.11530@waikato.ac.nz> <9430@cbmvax.cbm.commodore.com.commodore.com> Reply-To: jay@mitisft.UUCP (PUT YOUR NAME HERE) Organization: Unisys Network Computing Group, San Jose Lines: 95 In article <9430@cbmvax.cbm.commodore.com.commodore.com> mitchell@cbmvax.cbm.commodore.com.commodore.com (Fred Mitchell - PA) writes: >In article <1990Jan13.105048.11530@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro) writes: >> >>MultiFinder has been accused of not having "true" multitasking, >>in that it requires applications to cooperate and not hog >>the CPU to themselves. >>... >>In summary, a personal computer system needs *cooperative*, >>not competitive, multitasking, ... > >I _very strongly_ disagree. On the Amiga, you have the best example of >pre-emptive multitasking that I have ever seen on a micro. And the number >ONE thing that you have is SPEED! If my program dosen't have to make >repeated calls to the OS, it can run that much faster. I don't see any >advantages to having a 'cooperative' OS at all. It tends to get in the way, >and hints at a fundamental flaw in the initial design. I fail to understand >why Macs can't go pre-emptive anyway. All you do is save all the registers, >go to the next task, and load that task's registers, and hop right in where >it left off before! Shared resources can use semaphores to arbitrate usage. >Sound pretty simple to me! Why is that not possible under the Multi-Finder (or >Finder for that matter)? :-( Sigh... Will this never end? For nearly 10 years I was an O/S Software Engineer for a company that had it's own proprietary COOPERATIVE multitasking O/S. It is _very_ possible to have an effective, efficient cooperative multitasking O/S. In terms of efficency, a cooperative multitasking scheme has less overhead since processes aren't being switched while they have useful work to do. In terms of effectiveness, no application had any effect on the response of another. It worked well because the system was very I/O intensive. All this I/O time was available for other processes. Badly behaved applications that didn't release the CPU were detected very quickly during development. Only one application (the assembler) had O/S calls inserted in the code to explicitly give up the CPU. This was the most CPU intensive application on the system. It is not as simple to implement a preemptive multitasking O/S as you indicate above. The entire state (context) of a process must be saved between process switching. Unfortunately, the processor registers are not all of the process context. On the Mac, currently the only place where a process state can be guaranteed to be stable is at the process switch times Apple has defined for MultiFinder (GetNextEvent, WaitNextEvent, etc.). Even the UNIX kernel doesn't preemptively switch processes while executing in the kernel. It doesn't need to - perfectly reasonable response can be acheived without it. But it does interfere with Unix's abiltity to be a real-time O/S. I point this out to illustrate that even what many people consider to be the foremost preemptive multitasking O/S isn't perfectly preemptive. But people don't complain about Unix (unless they want a realtime O/S). All this is not to say that MultiFinder is perfect. Flaw number one is that processes don't switch during disk I/O. Even if they did, I'm not sure how effective that would be without DMA. Flaw number two is that all output to the display is very CPU intensive - obviously. In a serial terminal based system, a cooperative multitasking O/S can service other processes during screen updating - the Mac can't. Instead of debating the merits of preemptive vs. cooperative multitasking O/Ss, why not debate the issues that would make the Mac a more effective multitasking system regardless of the policy used - THE MAC NEEDS DMA AND A QUICKDRAW COPROCESSOR. Let's identify wasted CPU time and gripe about how that time isn't being given to other processes. On a similar note, some people on the net have griped about how the Mac doesn't have (and won't, even under 7.0) _protected_ virtual memory. How about getting a discussion about this going. I understand _why_ it's going to be difficult to implement seperate protected address spaces for processes - the question is what is going to be done to the Mac O/S to overcome these hurdles in the future. One problem that has to be taken care of are data structures (such as the window list) that currently logically thread their way through what would be all process address spaces. > >>...not as a cut-down version of a multiuser operating system. I >>think even round-robin time-slicing (forced periodic rescheduling) >>of tasks is a bad idea; it costs CPU cycles to implement, > >Not nearly as much as cooperative costs you! False. Cooperative costs LESS if implemented correctly. See above. The Mac needs to have more time spent waiting for I/O. > >Then again it's unfair to compare a personal computer to a multi-user >system. (Or is it? :-) The boundaries are blurring. The one boundary that I hope will remain intact is that personal computers are not shared by multiple people at the same time. I'd like to see the Mac evolve into an efficient multi- tasking system, not a multiuser system. (now getting down off my soapbox :-) ) > > -Mitchell > mitchell@cbmvax.UUCP Jay O'Conor UNIX O/S Sofware Engineer Unisys/Convergent