On Fri 11 Aug, Byron Hale wrote:
> Also, garbage collection is unlikely to satisfy any need
> for automatic memory management in real-time systems for the foreseeable
> future because an extra thread on a single processor is still
> non-deterministic.
I'm not sure this is true, doesn't it depend on the scheduling strategy?
I've written a lot of code for single and multiple processor DSP systems,
and typically have multiple threads (on 1 processor).
But they are still entirely deterministic.
BTW, I've never really understood how it is that garbage collection is
a separate thread in Java (as I've heard it is, but I have never used Java).
The implication is that somehow Java progs keep running while garbage
collection is performed concurrently.
Is this true? If so how does this work?
It seems to be a hard thing to do if the GC uses pointer some variant of
mark-sweep and pointer reversal. I guess if reference counting and fixed
cell size was used this could be possible, but this won't work with cyclic
data structures.
My objection to the use of GC (and by implication all current Haskell
implementations) in embedded systems would be that if your program is
sufficiently complex/powerful that it can't be implemented as some kind
of _finite_ state machine, then it can never be part of a robust system
(which has finite memory resources). Put simply, if you don't know how
much memory you need, how can you ever be confident you have enough?
Hmm, now having written that, I'm wondering how the Erlang community
addressed this problem. I believe Erlang is targeted at applications
which I would class as 'embedded'.
Anybody know the answer?
It seems a sad irony if the memory management techniques used to implement
declarative languages (which are designed to ensure program 'correctness',
aren't they?) also ensure program 'flakeyness' at run time (on real machines).
Regards
--
Adrian Hey
