ian@sibyl.eleceng.ua.OZ (Ian Dall) (06/15/90)
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.
karsh@trifolium.esd.sgi.com (Bruce Karsh) (06/18/90)
In article <682@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >I guess this discussion only has a place in comp.arch *if* it >influences the requirements on the hardware. This is comp.arch, not comp.hardware. The software architecture of a computer system seems to be a lot more important to computer users than the hardware architecture. I think we need a lot more discussion of software architecture. Certainly something is wrong with present ideas of how system software should be architected. Unix machines and their ilk are expensive and not very popular (except with programmers). Trying to get work done on them is painfully slow. There is practically no good end-user software available. It's been this way for nearly twenty years. If Unix is the present idea of how system software should be architected, then clearly something is very wrong. From the recent traffic on this newsgroup, it looks like the Mac-style very small architectures are not well received by programmers. However, they have been very well received by their users though. If the modern view of software architecture can't account for the success of this kind of architecture, then there's something very wrong with the modern view. Bruce Karsh karsh@sgi.com
dmocsny@minerva.che.uc.edu (Daniel Mocsny) (06/18/90)
In article <62367@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: >In article <682@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >>PC's and mac's [...] have no immune system. >...there are so few Unix systems that it's not worth peoples time to >bother writing them. This is still in keeping with a biological analogy. Since pathogens generally target some specific population of host animals, the larger the population of any single host species, the faster the pathogens can mutate, grow, and propagate. In a natural ecosystem, with thousands of plant and animal species competing for space and food, the relatively small population of any single species helps keep bacterial and viral plagues in check. But when one species of animal (e.g., Man) wipes out most of the other animals and populates huge communities, the name of the microbial game becomes, "Infect Man." So while fragmentation in the UNIX market destroys much value by reducing software availability and complicating life for the users, it does present a significant barrier to the spread of infectious programs, just as a differentiated ecosystem is less subject to devastating plagues. However, I think that is a silly way to justify failing to standardize UNIX. We would be better off incarcerating people who write computer viruses. -- Dan Mocsny Snail: Internet: dmocsny@minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171 dmocsny@uceng.uc.edu University of Cincinnati 513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (06/18/90)
In article <62369@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: > >This is comp.arch, not comp.hardware. The software architecture of a >computer system seems to be a lot more important to computer users than >the hardware architecture. An excellent statement. > >I think we need a lot more discussion of software architecture. I agree >Unix machines and their ilk are expensive and not very >popular (except with programmers). Not all Unix machines are expensive. The most popular, by far, Unix machines, those using the most popular Unix CPU, the 80286/386/486, are no more expensive than their PC brethren, because they are the same. >There is practically no good end-user software available. >It's been this way for nearly twenty years. If Unix is the present idea >of how system software should be architected, then clearly something is very >wrong. > The reason there is no good end-user software, except a few public domain things, is that until recently there was no industry-standard platform to run binaries on. Now that there is (386 PC clones), that might (or might not) change. There certainly exists a critical mass of machines out there. But there needs to be a critical mass of software, that can be bought at stores in malls. It will be interesting to see. To return to the subject of software architecture, I think a good topic of discussion might be windowing systems. However, there is already a group (comp.windows.misc) to which it might retire. Doug McDonald