Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!mdavcr!ewm From: ewm@mdavcr.UUCP (Eric W. Mitchell) Newsgroups: comp.sys.mac.system Subject: Re: PPC, IAC, and True Multitasking (tm) Message-ID: <923@mdavcr.UUCP> Date: 21 Aug 90 23:38:02 GMT References: <1990Aug3.040513.14844@d.cs.okstate.edu> <2760@bridge2.ESD.3Com.COM> <13888@cbmvax.commodore.com> Distribution: na Organization: MacDonald Dettwiler, 13800 Commerce Parkway, Richmond, BC, Canada V6V 2J3 Lines: 120 In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Actually, you either have pre-emptive multitasking, or you have nothing. Taking >it your way, my Apple II has cooperative multitasking since it allows me to >load two specially written executables at two different locations, which then >branch into each other when they have completed part of their task. This is a rather poor example. A hard coded, explicit branch between two pieces of code is hardly what happens in "cooperative multitasking". >Of course the Mac has much more built-in support for such a cooperative effort, >but multitasking is not a feature which can be quantitized. Either you have it, >or you don't. An operating system has a pre-emptive scheduler, or it doesn't >have one at all. There is no such thing as a cooperative scheduler. The term >cooperative is used when there is an absence of a scheduler. In both "preemptive" and "cooperative" multitaskers, there is a piece of system code that priortizes and hands control to running processes based on some internal criterion. The only significant difference is that preemptive systems can interrupt execution of a process and cooperative systems can not. Cooperative systems rely on the process to return control to the scheduler in a "reasonable time". You will note that most (or perhaps all) preemptive multitaskers support some kind of ability to turn off the preemptive ability of the scheduler while running certain processes; for example, timing-critical applications, system routines, etc. Effectively, the scheduler becomes a *cooperative* multitasker until the process ends, and gives control back to the scheduler. In fact, the scheduler itself is effectively a "cooperative" task, handing control to other software in the system when it is good and ready. Real time systems in particular usually include some ability to lock out "preemption". Both preemptive and cooperative multitaskers have their advantages. Preemptive systems are typically less reliant on good programming habits of the software developers. >You misunderstand the concepts behind (pre-emptive) multitasking. The idea is >to have the kernel interrupt the task in progress if another task of a higher >priority is ready to run or if the quantum of the current one is over. If there >is no other other task ready to run, task switching never occurrs. You obviously have a good understanding of how preemptive multitasking works, but I think your rather dogmatic denial of other flavors of multitasking is somewhat silly. Multiple types of multitasking have been around for years. It is widely acknowledged and accepted (my university certainly did, anyway). Go ahead and argue the relative merits of various multitasking schemes, but don't deny that the others even exist! >If anything, a preemptive operating system will be faster, because it will >perform task switching only when necessary. The preemptive operating system >will also allow the user to set task priorities. Thus if the user wants task B >to run only when task A is waiting for an event to complete, all it has to do >is lower its priority below that of task A. *bzzzzzt* Wrong. A preemptive system will often be more *responsive*, but it is not *faster*. Actually, the word I think you should have used here is "more efficient", because you were arguing about system overhead due to task switching. However, you are basically incorrect anyway because preemptive multitasking slows down the system because it adds to the number of cycles required to perform a given operation. In this area, cooperative multitaskers are usually more efficient than preemptive systems. This is because a cooperative multitasker lets go only at suitable times. Thus instead of being preempted in the middle of a loop of calculations, a program will wait until a more appropriate point in the code - such as while waiting for I/O - to release control back to the scheduler. In general, this results in better utilization of CPU cycles. A preemptive system can certainly do this as well, but if the code does any operations where it has to wait for resources, execution becomes less efficient. Consider if the scheduler preempts an operation just before it makes a request for some resource - a task switch is made, then when control is returned to the process, the resource request is made and the scheduler must switch applications *again*. Two task switches where one would have been performed in a cooperative system. A general rule (that many others may not agree with) is that a cooperative scheduler is fine for systems that involve a lot of I/O, and a preemptive scheduler is better if you are running a lot of batch programs. Cooperative multitaskers are NOT suitable for many systems, whereas you could probably use a preemptive multitasker wherever you put a cooperative system. In the later case, you may actually suffer a performance drop, but it all depends on the system configuration. I certainly wouldn't put a cooperative multitasker in a multi-user system. I also wouldn't want one on a development system (too subject to programmer errors). But that's my opinion only. >Thank you for your support. > >Valentin Don't be a smart-a**. Eric ============================================================================== Disclaimer: PAY me for my advice, then I will take responsibility for it. Thus I am responsible to my company, but they are not responsible for me. --------- "Hmmm, MacDonalds? A&W? Hey! Kentucky Fried!!!" - Wiley Coyote gets smart