Re: Another request from a Newbie :-)

At 2003-05-16 09:53:27+0000, "Tobias Ritzau" writes:
> > Real-time GC is difficult, but not impossible.  Harlequin did a
> > real-time Common Lisp, with contractual limits on pause times.
> 
> Sure there are such GC's. I list four such techniques in my previous
> posting. The problem with most (other) "real-time" garbage
> collectors is that they don't guarantee memory availability. It is
> common to say that you have a real-time GC if the worst-case
> interrupt time is below a specified threshold, but that does not
> mean much if you have no guarantee that the GC progresses
> sufficiently (I'm not sure whether Harlequin's GC guarantees this or
> not.)

Yes, it did (for the application for which it was originally developed).

> There are even cases of GC techniques that claim to be real-time
> since the shortest measured interrupt time is X. This is simply not
> enough for hard real-time.

I disagree.  Many (I might even say most) real-time applications are
developed using exactly that kind of measure, often with a specific
(maybe highly demanding) test suite.  Some real-time applications
(e.g. safety-critical systems) may have a more rigorous method for
ensuring that real-time constraints are met, but many, many
applications do not.

Yes, this may well mean that those applications fail in deployment
(when they fail their time constraints due to circumstances outside
the scope of their test framework).  This is, of course, normal for
software (just as, say, a C compiler may fail due to memory exhaustion
if you turn on heavy optimization while compiling a great big switch()
statement).

By the way, I follow many practitioners in disliking the term "hard
real-time".  Real-time is real-time: a late answer is a wrong answer.
So-called "soft real-time" (e.g. tracking a mouse in an office
application) is better described as "interactive" or some such (and
can often be satisfied by merely incremental, or even
pseudo-incremental, GC).

> And again, to be able to guarantee memory availability, you must
> know how much memory your application requires.

Agreed.

Nick B