execution time becomes unpredictable?!

[Richard Bos]

I don't know if there is a formal name like "Buddy System"
for what I was thinking of. Consider, though, a system which
is written to only merge together blocks to produce larger
superblocks with magic size and alignment properties.

This sort of merging is trivial if handled by a bitmap, but
if for some reason this kind of merging was being done -and-
there was the traditional "each free block points to the
next free block" chain, then a number of pointer fixups could
end up being done.

Sure. But I'd call that a very unsmart implementation. Buddy system with
bitmap, OK. But a chimaera of two systems is hardly ever a good idea.

Richard

 

[Kevin D. Quitt]

In the company I work for, it was always the later. No big whoop, I guess.

I doubt there are many instances of sophisticated embedded systems that
are fixed-time deterministic. If you have interrupts, you cannot be
fixed-time deterministic.

A system is deterministic iff you are *guaranteed* that every task will
complete its function within the time allowed or before its required
completion time.

 

[Flash Gordon]

I doubt there are many instances of sophisticated embedded systems that
are fixed-time deterministic. If you have interrupts, you cannot be
fixed-time deterministic.

You can still be fixed-time deterministic for sections of the
application which, in my experience, is all that is required. You just
have interrupts disables for the critical periods which is in my
experience easy to arrange since the critical periods are often
triggered by an interrupt.

A system is deterministic iff you are *guaranteed* that every task will
complete its function within the time allowed or before its required
completion time.

This can be analysed and proved to be correct. On the systems I worked
on we always made timing estimates as part of the requirements analysis
and refined them during the design phase.

 

[REH]

guess.

I doubt there are many instances of sophisticated embedded systems that
are fixed-time deterministic. If you have interrupts, you cannot be
fixed-time deterministic.

A system is deterministic iff you are *guaranteed* that every task will
complete its function within the time allowed or before its required
completion time.

Agreed, but I gave up trying to argue the point here.

 

[REH]

You can still be fixed-time deterministic for sections of the
application which, in my experience, is all that is required. You just
have interrupts disables for the critical periods which is in my
experience easy to arrange since the critical periods are often
triggered by an interrupt.

Have you ever work on a large scale real-time system? The above is simply
unacceptable. You have to (al least in my job) guarantee that EVERY
dead-line will be met. Plus, there are a lot of events that simply cannot
be tied to in interrupt. Even for the ones that are, locking interrupts is
a bad thing. You introduce drift, increase interrupt latency, and inhibit
the scheduler. The periodicity of (most) every task must be shown to be
achievable.