Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!sibyl!ian From: ian@sibyl.eleceng.ua.OZ (Ian Dall) Newsgroups: comp.arch Subject: Multi-tasking, and immunology (was Macintosh OS) Message-ID: <682@sibyl.eleceng.ua.OZ> Date: 15 Jun 90 02:04:51 GMT References: <8767@odin.corp.sgi.com> <369@three.MV.COM> Reply-To: ian@sibyl.OZ (Ian Dall) Organization: Engineering, Uni of Adelaide, Australia Lines: 48 In article <369@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > >... A well written set of cooperating >tasks will run at least as fast as a set of preemptively scheduled tasks. >On a GUI based system, they will run (as perceived by the user) better. The >Current Application will complete actions for the user and then, while the >user is thinking (i.e. the CPU is idle) do other things. Swapping at event >time when there are no pending events is the best time for such things. There >is no way that a purely preemptive MT system can always preemt at such times. You have totally failed to convince me. For a compute bound task, no time is any better than any other to swap (assuming swapping is necessary). Assume we have a number of different interactive applications in different windows, if the user causes a (keyboard or mouse) event in a window, a premptive system can get the interrupt and begin wakeing up the correct process immediately. This might stop another process at an inopportune time, but who cares? As far as the perceived speed of the system is concerned it is the speed that the selected interactive process responds that matters, not that a bit of overhead might have been saved somewhere. In fact, I would hazard a guess that a "cooperative multitasking" has precisely the opposite characteristics to what you suggest. It might be slightly faster on average throughput but will be *slower* to respond interactively. The only way it wouldn't be slower interactively is if the frequency of polling for events is so high that the time spent in the get_next_event function blows away any reductions in overhead. I guess this discussion only has a place in comp.arch *if* it influences the requirements on the hardware. I can't see that it does really. You don't need a cpu with interrupts if you do cooperative multi-tasking, but are there any modern machines without interrupts? The "shared address space is best", hypotheses has architecture relevance (because you don't need a mmu) but as far as I can see the two (shared address space and cooperative multi-tasking), are independent features (or bugs :-) ). A recent virus plague here caused me to ponder whether *that* might spell the end of "single shared address space" machines. Part of the reason that viruses spread so fast on PC's is the plug and pray software idiom, but the other reason is the total lack of any security on the machine. I know proper operating systems are not immune, and I know about the internet "worm", but at least Unix has a security system to overcome. PC's and mac's are wide open. In effect they have no immune system. My hypothesis for the week (following the biological analogy) is that MSDOS machines and macs have aids. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.