Sorry - I did edit a little too much I guess. But your definition
wasn't really right either, IMHO. See below...
> > One of the key points of a realtime system is that any latencies be
> > bounded. That's something you'd have one hell of job claiming for a lot
> > of OS/app combinations. Don't mistake "usually adequately fast" for
> > "realtime".
>
> Now, where does it say anything about "bounded latencies". By what
> authority? Since I defined realtime, I would like to know how
> an additional definition got appended to destroy the concept.
I think we're on different wavelengths: "realtime" does have a meaning
outside any definition you choose for it. I'm used to a particular
definition for "realtime", and of course if we use yours then my
comments are meaningless.
> Again, an operating system is realtime, if it can respond to
> external events while they are still current.
>
> To carry this to its logical conclusion, it becomes obvious
> that buffering or queuing does not help because once the second
> event gets into a buffer, or onto a queue, the first is no longer
> current.
I totally disagree. This is not what the rest of the planet means by
realtime. I can define a realtime OS which must respond to events while
they are current but this does NOT preclude having multiple events
simultaneously - unless "current" is defined rather narrowly.
I agree that an 8088 could run a RT OS, no problems. I don't think that
you can formally prove that CP/M and BASIC will work though.
> If you want an OS that chops every task's CPU usage into, say,
> microsecond intervals, to obtain microsecond latency, you are not
> defining "realtime", you are defining an entirely different concept
> which is called controlled latency.
But how can you promise the customer that your system will respond to
events while they are current if you DON'T control the latency?
This is the crux.
Neil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/