Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!bwc From: bwc@waikato.ac.nz (Ug!) Newsgroups: comp.sys.acorn Subject: Re: 'operation systems' Message-ID: <1991Jul1.131540.4117@waikato.ac.nz> Date: 1 Jul 91 01:15:40 GMT References: <1991Jun27.191439.28073@rusmv1.rus.uni-stuttgart.de><1991Jun28.083032.4097@waikato.ac.nz> Organization: Voonyercity fo Kaiwatoe Lines: 66 Andrew Stevens writes: > > Firstly, it is not at all clear that pre-emptive multi-tasking has > higher overheads. Size or time? There's a lot of support stuff, and arbitration mechanisms that aren't needed with a cooperative sheduler (semaphores, scheduling mechanisms, priorities, etc), and all that can take time. Also, a preemptive task generally needs more state. > It is harder to bolt onto an intially single-tasking > substrate agreed, but not significantly harder to implement from the > ground up. Existance proof: kernel of QL operating system, OS/9, etc. Yup! > Further I would say the overhead for RISC-OS's co-operative > multi-tasking is high. Just try timing a few things with and without > significant multi-tasking. UNIX (say) looks wonder-slick in comparison. Unix? You gotta be kidding! Unix is anything *but* real time. Of course, that does depend very much on the Kernel. And anything which needs real-time can still be done with RiscOS - just run it off an interrupt. > That said, however, I suspect the much of the clamour for pre-emptive > multi-tasking under RISC-OS would disappear if the co-operative > multi-tasking was more sophisticated. E.g. > > 1. The current process scheduler seems minimal to say the least. It is > hard to write programs that won't (unintentionally) either starve or hog > the CPU. Yeah - it's not the greatest, but it's better than many I've used. > 2. There don't seem to be any easily accesible goodies to allow > processes to tick away in the background when desired. E.g. something > to trigger CPU release based on some *standard* scheduling interrupt. > In effect: the functionality of the TASK module available when needed to > any RISC-OS program. That would be good - a generalised Background Task mechanism would be great. That sort of thing should be extended to nearly every resource, as in Apple Mac's system software. That has 'managers' for sound, timers, etc... > Workable threads under RISC-OS would be quite hopeless without > refinements in this areas. Would you really always want a 3 thread > program to get 3 times as much CPU as a 1 thread program? Also, the > most useful application of threads tends to be to have something ticking > away in the background whilst a foreground interaction thread grabs the > CPU when it fancies it. Three threads doesn't equate to three times the CPU time. > This is almost certainly incorrect. Why swap in/out more than you have > to? Few programs are smaller than 32K (max. MEMC1 page size). A lot > are very much bigger. Even !Edit is 100 plus K bytes. I doubt it > would even be that much easier to implement. All the fun of delivering > interrupts etc to swapped programs would remain. I would agree that > demand paging should not be compulsorary, but it would be damn nice > if it were available when required. I don't think so. Most WIMP tasks probably don't work directly with interrupts anyway - more likely to be a Module, which wouldn't be swapped. Also, just as in demand paging, you need not swap *everything*, only what's needed. Ug!