Tue, 05 Sep 2000 David Schleef wrote:
> On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote:
> > Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> > > > > Let's say I have N message buffers in a pool. What if
> > > > > there is no more free buffer?
> > > >
> > > > Then the design for your hard real
> > > > time system was wrong :-)
> > >
> > > Or system reached its limits.
> >
> > Yep, and the only options are a) redesign and b) upgrading the hardware.
> >
> > > It depends on your possibilities and intentions.
> > > What if amount of incoming data is unpredictable but you have
> > > to process at most as you can with a limited hardware?
> >
> > That's a kind of *soft* real time system, which is not really what RTL is
> > intended for. (Although the input->"some kind of output" latency could have a
> > hard RT requirement - but the memory allocation would still be soft RT.) You
> > can't optimize a single API for both hard and soft RT, at least not without
> > making it a major PITA to use if you want hard RT, so IMHO, it's a very good
> > idea not to mix these two kinds of systems up when discussing APIs.
>
> I don't think that "running out of memory" and "running out of CPU
> time" are fundamentally different things. It's just that with a
> memory allocator, you are notified of a lack of resources and can
> do something graceful instead of locking the machine.
Yes indeed; but still, if either of these things happen, you don't have a hard
RT system. Hard RT systems shouldn't have to worry about missed deadlines OR
running out of memory (or any other resources), as they have already failed if
they ever get into that situation.
Or; it's a good idea to handle every possible error condition nicely (within
reasonable limits!) as that makes debugging a lot easier, and it *might* save a
buggy hard RT system a few times, until the effect of the bug coincides with a
critical situation. And, as hard RT actually isn't in real life, improving the
statistics is a good thing. However, I believe *designing* around that
philosophy will result in serious problems sooner or later.
A general rule of all kinds of programming:
Fix design problems as you find them - don't burry them in code.
David Olofson
Programmer
Reologica Instruments AB
[EMAIL PROTECTED]
..- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
