Re: garbage collection thoughts... again?!

[David Olofson <david@...>]

(I think it's time to clear up some misconceptions here...)

On Saturday 31 May 2003 15.56, Roberto Ierusalimschy wrote:
[...]
> * Whatever the final algorithm, it should be clear that it will
> need some cooperation from a programmer to achieve soft real-time
> performance.

By the definitions I know of (and that matter in the real world, where 
I live and work), Lua already seems to do *soft* real time just fine. 
Deadlines can be met most of the time, although some will be missed 
every now and then. That's *soft* real time.


> There will be short pauses to traverse the stack(s),
> to clean weak tables, etc.

How short? "Short enough" is fine by me. You need to use a CPU that's 
fast enough for the job, no matter what.

Can the worst case delay be bounded? Yes, if the algorithm is right!

If there's a guaranteed (*) worst case latency for any particular 
hardware (ie you can predict how much work the GC will do in any 
given situation), it *is* hard real time.

Hard real time is *not* about speed. It's about deterministic 
behavior. If I need some system to react within one minute (or we 
have a reactor meltdown, or whatever), I don't care if it *can* 
respond in 50 µs. I just need to know that it will never ever fail to 
respond within one minute.

(*) The are no TRUE hard real time systems in the real world.
    They are not possible to implement without indestructible
    and completely stable hardware. What most "RT people"
    (control engineers like me) call "hard real time" actually
    means "the risk of missing a deadline isn't much bigger
    than the risk of the hardware spontaneously frying."
    Hardware *does* fry. Some bug or miscalculation *might*
    cause a response to be slightly late every few thousands
    of hours or so. That's why really critical systems have
    watchdogs, fallback systems, multiple redundancy, or
    combinations thereof.


> (Cooperation here means things like to
> avoid the use of too many weak tables or other similar rules.)

Of course. No system is stronger than it's weakest link. If an RTAI or 
RTLinux application has non-deterministic code in the hard real time 
path, it will not, and cannot ever be, a hard real time application.


> There is no chance to achieve hard real-time performance.

Sure there is. Hard real time != microseconds. Hard real time == known 
absolute worst case latency.


> I doubt
> this is possible with any scripting language.

No personal experience, but I think SuperCollider proves the opposite.

Either way, what is so special about scripting languages that they 
cannot be used in hard real time applications? What's so special 
about C that it *can* be used in hard real time systems?

I'm 99.99% sure the answer to that is "nothing". We're just talking 
about code here. If we rely only on deterministic algorithms - no 
matter what they're doing - we can have a hard real time system.


> This is difficult
> even for hard languages doing dynamic memory allocation.

Yes, it's a different set of rules from what "normal" application 
developers are used to.


> (First you
> need a "malloc" that never returns NULL...)

Well, that's the fist thing everyone gets wrong. DON'T use dynamic 
allocation in the first place. Simple as that.

BTW, "never running out of memory" is not a useful definition in this 
context. (It would be more useful to normal applications.) What are 
you going to do with all that memory anyway?

You can use pre-allocated buffers, pools of pre-allocated objects, and 
you can even have something that looks like a normal memory manager, 
but that is hard RT safe. That's still some form of "pool of 
pre-allocated objects", though.

Either way, you have to realize that if you design your system in a 
way that makes it possible for any combination of events to make it 
run out of memory, it is not a hard real time system. No hardware, no 
operating system and no language can save you if your design is 
broken.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---