Thread: What is the alternative to malloc?

I think this is because embedded systems usually have there own specific means of dealing with memory management.

After a little google I noticed that MISRA's own stance on this is that they will not recommend anything, and in particular they do not recommend malloc.

> As we all know, one of the MISRA C rule discourages the use of malloc for dynamic memory allocation.
There are too many variables:
- where it get memory from
- how blocks are allocated
- how blocks are freed
- how fragmentation is dealt with
- is it even thread safe

I've seen one malloc/free in the past, where if you freed memory in the "wrong" order, then it would take 1000's of times longer to free the memory than if you freed it in the "right" order.
This kind of random behaviour is something you don't want in an embedded system.

You start with something like
char pool[1000000];
and you write myMalloc etc yourself.

There are all sorts of strategies you can take when you're tailoring the solution to a particular problem (eg. using a pool approach where only fixed sized blocks are used).
Allocating and freeing may waste a bit of memory, but they become very deterministic.

In high criticality code (which is what Misra C aims to support) there is generally a requirement for determinism i.e. complete predictability. Dynamic memory allocation and deallocation is not completely predictable for the sorts of reasons (like those mentioned by Salem).

The reason that Misra do not recommend anything is that whatever is done is required to be justified by analysis suitable to the application and approved within some specific context.

The most common strategy I've seen in high criticality systems is that all memory required by a program is allocated during program initialisation/startup and, once initialisation is complete, memory allocation is forbidden. Within that, the memory used by any particular function is predetermined at program startup. Some specific justification may sometimes be put forward for approval to use dynamic memory allocation (eg malloc()) during program startup and subsequently forbidding its usage.

If a MyMalloc() function to access some global pool is used, there are very specific restrictions on its behaviour and usage. It can't be used as a "poor man's" malloc()/free(). Specifically, code could only use it to grab a specific block that is fixed at program design time (i.e. a function could not obtain some arbitrary block at run time and later release it). Otherwise, it would be forbidden, as it has potential to exhibit the same type of non-determinism associated with malloc()/free().

Originally Posted by huwan

So, at the first place we must be sure of how many/much memory our program needs?but this could probably leads to memory waste/insufficiency if our estimation is wrong, am I correct?

Where/what is this suppose to run on? I don't do embedded programming, but I presume you should know everything that is going on there, how much memory there is, and be able to decide how much memory a process will need. If you are going to run processes in parallel, calling one within another, maybe you need to take that into account too.

But it is not really waste IF you take all available memory when no other possible process could have needed it, right? That memory would have just been unused.

Vis, insufficiency, yeah, that would be a problem, so don't under estimate. Over estimating won't matter as long as you don't ask for more than what exists (which I guess should fail immediately).

Originally Posted by huwan

So, at the first place we must be sure of how many/much memory our program needs?but this could probably leads to memory waste/insufficiency if our estimation is wrong, am I correct?

For programs of significant criticality, it is necessary to perform whatever analysis and supporting measurements are needed to properly characterise memory usage (and usage of other resources) by each critical function. It is also necessary to provide sufficient evidence to satisfy an independent reviewer (or regulator) that the analysis provides sufficient assurance for the intended application.

Originally Posted by MK27

But it is not really waste IF you take all available memory when no other possible process could have needed it, right?

It is if there is a requirement to make provision for the system to evolve in future. If existing processes consume all available resources, then it is not possible to provide any assurance that a proposed new process will receive the resources it needs. It is also more difficult to give assurance that modifications of existing processes will not require more resources than made available to them.

Incidentally, not all embedded systems require rigorous analysis to ensure their correctness. The process of design, implementation, and assurance for an MP3 player is generally less rigorous technically than a pace-maker.

free() is used and alternate of malloc, used to deallocate memory....

Yeah was just checking out....
Does this really bad to reply to older threads??

Okay... Gotcha... Peace.... :-)