Isaac Marino Bavaresco wrote:

> Gerhard Fiedler escreveu:
>> One of the main issues here is that dynamic memory is not
>> predictable. Usually you need to make sure that in the worst case
>> scenario (per spec) the available memory is enough (queue length,
>> etc.) With dynamic memory, you don't even know before-hand how much
>> usable memory you have, due to fragmentation. Only a 'designed'
>> memory solution can give you that. With this in mind, malloc et al
>> is generally out of the picture anyway.
> 
> Not always true. I have a system where there are a few types of
> dynamic data, and all of them have fixed sizes. What changes is how
> many of each type is needed at any time. And sometimes when one type
> is in use, by design, other types are not needed.

This is exactly what I'm talking about. You need to "design" the memory
usage; you can't just use willy-nilly malloc/free the way you'd do it in
a typical desktop or server application.

So, even if you use malloc/free, you need to design how much of your
memory is needed, worst-case, for every part where you use dynamic
memory, you need to design how much of it is needed in total,
worst-case, by all parts that use dynamic memory together, and you need
to design how heap fragmentation plays a role in that and make sure that
you have the memory available that you think you have. 

To me, this looks much more like a custom memory handler, even if you
use malloc and leave the enforcement of the design constraints
completely up to the programmer. I'd probably say it's safer to make
sure (explicitly, with code) that these constraints are met, than to use
plain malloc and hope that the implementation fits the constraints. 

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist