Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!newcastle.ac.uk!sylvaner!q1aqf From: A.Waterworth@newcastle.ac.uk (A Waterworth) Newsgroups: comp.realtime Subject: Re: AmigaDOS as realtime system? Message-ID: <1991Mar1.100809.27673@newcastle.ac.uk> Date: 1 Mar 91 10:08:09 GMT References: <1566@swrinde.nde.swri.edu> <1991Feb27.090231.5412@newcastle.ac.uk> <1991Feb28.194655.1294@eecs.wsu.edu> Sender: news@newcastle.ac.uk Organization: University of Newcastle upon Tyne, UK, NE1 7RU Lines: 115 pcooper@eecs.wsu.edu (Phil Cooper - CS495) writes: >In article <1991Feb27.090231.5412@newcastle.ac.uk> A.Waterworth@newcastle.ac.uk (A Waterworth) writes: >> >>I probably won't be the only one to mention this, but here goes anyway... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [ My stuff about predictability in real-time operating systems etc.] > > Well, you are the first one so far... Well, it comes as a surprise to me that I am 'the first one so far' - maybe most of the people I know who are working on real-time hardware and software don't read this group? > Adrian, it should be obvious to you that any OS which operates in an >interrupt-driven environment (not to mention multitasking), would fail the >requirements you have set forth for a real-time OS. Not necessarily - a decent real-time OS should be sufficiently predictable in it's own behaviour and flexible in the services which it provides that it will allow an application programmer to write software in such a way that guarantees of timeliness _can_ be made for some critical subset of real-time tasks (possibly all of them). That should be true even in an interrupt-driven, multi-tasking environment. (Any specification of a real-time system should include information about the frequency and relative importance of asynchronous events such as interrupts, as well as information about which tasks need to be run and under what conditions. Given such data, interrupt handling and multi-tasking can then be handled in a predictable fashion - although you may find that the available hardware is not powerful enough and you've got to fork out more cash!) > If you are collecting >data and monitoring events from several different sources, some with higher >priority than others, an unfortunate sequence of interrupts could prevent >lower level requests from being processed. In reality, this would be a rare >(if not unheard of) event, but still plausible. To meet your requirements >you would need a single-tasking, polled I/O system with a seperate micro- >processor dedicated to each data collection (I/O) port. And then, you >would need to ensure that your processing code would complete its work >before the next event arrived (every time). Or, you could buffer the events >to be processed, but what if the buffer fills? Of course, this raises the old issue of soft and hard real-time tasks. If you are performing some kind of data-logging or data acquisition and you occasionally miss deadlines, then it doesn't really matter - you can probably afford to miss the occasional sample (unless you're working on something extremely strange). However, the types of real-time task which I have had to consider over the past few years are much more unpleasant - they're the kind of task where missing deadlines can, at best, cost you $$$$$ and, at worst, get people killed. Under such conditions, you just do not want to be falling outside your timing constraints - period! When data acquisition is required as part of some task set in such a system, then it must be performed in such a way that it cannot lead to a catastrophic failure (so it either has to be pre-empted when more important things happen or you have to be sure that it's going to work right every time). > Also, if you are going to take someone to task about a posting, please >do not edit it so much that it is barely recognizable. Kent Polk's posting >was very informative, and provided an excellent example of how Amigas are >used to do real-time processing. Now just a minute pal - you're starting to get on my wick here. 1. I was not taking Kent Polk to task about his posting. It _was_ informative and did provide an excellent example of how Amigas are used to do "real-time" processing. Except that the original question was whether AmigaOS is a real-time operating system and I was simply pointing out that it may offer a good starting point from which to develop one, but it is lacking in certain features which would make it suitable for general, or more particularly hard, real-time use. 2. I edited so much of the original posting out because I didn't want to go burning up bandwidth. I reckon anyone who was interested in this topic in the first place would have read the original article anyway, don't you? >It may not meet your definition, but then, I don't know of >any OS in existence that does. It's not just my definition - it's also the definition of a number of research groups and projects across the world. I'm not going to name drop because I don't need to - just check out any decent University library for recent (and even not so recent) papers. Oh, and you're right - at the moment there isn't any OS in existence that does meet the definition, although there are some that are starting to come close. Why do you think that there are large amounts of money being spent in the US, Europe and elsewhere to support leading-edge academic and industrial research into real-time systems? It certainly ain't being spent for the fun of it. >Are you an expert in the internals of the >AmigaOS? Have you ever used an Amiga for real-time processing? Have you >ever even SEEN an Amiga? I thought not. Of course I've seen an Amiga (silly boy!) OK, I will grant that I am no expert in the 'internals of AmigaOS' and that I have never used one for real-time processing. The latter is largely because it simply couldn't _do_ the kinds of real-time processing which I am considering (see above). However, having said that, does spending the last three years of your life working with research projects in real-time and safety-critical systems count for anything? I think that it probably should...?? Adrian. P.S. I'm still not 'taking anyone to task', so would people please refrain from ranting before they start. If I ever do have a real go at somebody's posting, believe me, you'll know about it. ______________________________________________________________________________ FROM : Adrian Waterworth. JANET : A.Waterworth@uk.ac.newcastle ARPA : A.Waterworth@newcastle.ac.uk PHONE : +44 91 222 6000 UUCP : ...!ukc!newcastle.ac.uk!A.Waterworth POST : Computing Lab. University of Newcastle upon Tyne, UK. NE1 7RU.