Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!ox-prg!culhua!as From: as@prg.ox.ac.uk (Andrew Stevens) Newsgroups: comp.sys.acorn Subject: Re: 'operation systems' Message-ID: Date: 28 Jun 91 11:28:01 GMT References: <1991Jun27.191439.28073@rusmv1.rus.uni-stuttgart.de> <1991Jun28.083032.4097@waikato.ac.nz> Sender: news@prg.ox.ac.uk Organization: Oxford University Computing Laboratory, UK Lines: 59 In-reply-to: bwc@waikato.ac.nz's message of 27 Jun 91 20:30:32 GMT Ug! writes: >As operating systems go, RiscOS ain't half bad. Okay, it doesn't support >preemptive tasking, but then, that's not necessarily a problem. With an >environment such as RiscOS, it provides all that's really necessary - >interrupt driven routines for background operations, and cooperative tasking, >which has lower overheads, and is generally more suitable to windowing >software anyway. I agree in principle with with Ug's comments here but not in detail. Firstly, it is not at all clear that pre-emptive multi-tasking has higher overheads. 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 etc.m 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. 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. 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. 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. >I don't think demand paging is the way to go for virtual memory on the >Archimedes (see previous comments) - task swapping (controlled by the > scheduler) would be more appropriate, and in the Archimedes case > (page size of 64K! Gak!) > probably faster... sad fact of life. 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. -- Andrew Stevens Programmming Research Group JANET: Andrew.Stevens@uk.ac.oxford.prg 11 Keble Road, Oxford, England UUCP: ...!uunet!mcvax!ukc!ox-prg!as OX1 3QD +44 0865 272563