Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!rochester!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: AmigaOS is real-time?
Message-ID: <16182@louie.udel.EDU>
Date: 24 May 89 22:30:14 GMT
References: <16100@louie.udel.EDU> <9881@watcgl.waterloo.edu>
Sender: usenet@udel.EDU
Reply-To: new@udel.EDU (Darren New)
Organization: University of Delaware
Lines: 23

In article <9881@watcgl.waterloo.edu> jvkelley@watcgl.waterloo.edu (Jeff Kelley) writes:
>The definition I use:
>Real-time: The ability to respond to REAL-world events, such as interrupts,
>	   in bounded TIME.
>
>The AmigaOS, and in particular Exec, disables interrupts for arbitrarily
>long periods of time.  For example, when a task loses the CPU because a
>higher priority task becomes ready, interrupts are disabled while the lower
>priority task is 'Enqueue'd on the task ready list, an operation for which,
>in general, an upper bound on the time cannot be specified.
>There are likely other areas, e.g. memory allocation, where similar
>situations occur (though I've only looked at the code for context switches.)

A couple of nits: First, I think memory allocation disables only
task switching, not interrupts. Second, a trivial upper bound can
be determined by checking how many tasks can be around at once
(memsize / TCB size). Also, 1/60 second is a good upper bound,
lest you loose the display. Third, I would think that the task switch
described above could be done without turning off the interrupts
since interrupt code is not allowed to look at such structures,
let alone change them.  However, I haven't look at the code myself,
so I am in no position to argue. But are you sure it is Disable() and
not Forbid() that is used? -- Darren