Comments on: Question of the Week: Do you use or allow dynamic memory allocation in your embedded design?

By: pohudet

pohudet — 2012年3月28日 09:28:00 +0000

I do trust all of the ideas you’ve presented to your post. They’re very convincing and will certainly work. Still, the posts are too short for novices. Could you please lengthen them a bit from subsequent time? Thank you for the post.

]]>

By: R. @ LI

R. @ LI — 2011年11月22日 20:39:37 +0000

“Mise en place” is a french phrase for “everything in place”, (typically in cooking,) which is the technique of having all ingredients pre-measured and chopped and sifted, etc, in little bowls around the work area. This allows the chef to create his masterpiece dishes without worrying about the (non-deterministic) ingredient preparation. You see this on TV cooking shows all the time.

A similar philosophy can be used in memory allocation. Take the actual allocation and freeing of the memory out of the critical response path. Do this by always having enough memory “chunks” pre-allocated for usage by the real-time events. The “softer realtime tasks” can ensure there are memory blocks available at all times, and can do the garbage collection and defragmentation.

]]>

By: D. @ LI

D. @ LI — 2011年11月22日 20:39:19 +0000

It’s all horses for courses really. I’ve used pre-allocated arrays of objects with in-place construction in some circumstances, written specialist memory managers by overloading operator new sometimes and used ordinary heap management other times. It really boils down to the size and dynamics of the system concerned.

One thing I am always dubious about though is garbage allocation and the languages that rely upon it. IMO the control of object lifetimes should be in the hands of the engineer, not a compiler run-time system, and relaxed disposal systems actually need more thought than simply using new and delete or malloc and free.

]]>

By: C. @ LI

C. @ LI — 2011年11月22日 20:38:58 +0000

I also prefer pre-allocating memory. But, going back to the original question, I think the simple answer is: it depends on the application. The key issue in real time systems is determinism. If you can use dynamic memory allocation and still ensure determinism, you should be alright. I like to play it safe and pre-allocate memory.

]]>

By: R. @ LI

R. @ LI — 2011年11月21日 16:03:26 +0000

I prefer preallocating memory (fixed or at startup, the result is the same) and using managed memory pools.per application. That gives us a lot of confidence that this is one issue we will not have to debug. One issue that no one has touched on is resource deadlock. When dynamic memory is shared between applications and there is not enough for everything at once — a legitimate case in resource-limited systems — then then code must be robust. Each application must assume that any allocation can and will fail. It must be able to back out and release any additional resources it has allocated and suspend until it can safely try again. It may be helpful to have a tool that analyzes the dynamic memory pool and identifies owners of the allocations. It should also provide statistics for identifying fragmentation.

]]>

By: D. @ LI

D. @ LI — 2011年11月21日 16:02:56 +0000

I would encourage people to please read what I just wrote regarding C/C++ versus garbage collected languages and our realtime garbage collector technology, in the above discussion thread. I would expect that many of us in this group have written or currently write large real-time systems (myself included). Analysis of deeply embedded systems memory usage is a requirement regardless of the language in use, as is worst-case-execution-time analysis, and the use of static analysis tools. Academic papers on the work-paced automatic memory management technology can be found on our website under the technology section.

]]>

By: J. @ LI

J. @ LI — 2011年11月21日 16:02:37 +0000

Interesting discussion.
Short answer: Don’t.

Long answer:
As many pointed out, dynamic memory allocation is almost tabu for real-time embedded systems. This is generally true when referring to a traditional global heap, using the allocate/free mechanisms available in C and C++. Memory fragmentation due to non-deterministic lifetime and granularity of data objects makes it unacceptable to use DM for mission critical systems.

I design bare-metal systems with over 180K lines of C code for mission-critical industrial systems, using no Heap. All real-time tasks have static allocation.
But it is also true that such systems make wide use of FIFOs, transmit/receive buffers and queues, as Mattias pointed out.
You have to analyse the usage data patterns and prove that you will never get out of memory for the critical part of the system.
However, use of fixed block heaps and dynamic allocation for the non-critical portions of the code, like sockets servlets and user interface objects, can reduce the RAM footprint for the system, without jeopardizing the core system. In this way, you can even use more than one heap, for each concern that has different usage patterns.

When designing deeply embedded, you need to know the details of memory allocation, RAM usage patterns and behavior for extended periods of time. The same is valid for automatic data objects that allocate RAM from the stack with long call chains.

]]>

By: D. @ LI

D. @ LI — 2011年11月21日 16:02:19 +0000

I guess I have to chime in when I read about hard realtime, garbage collection and Java. Our patented hard realtime, preemptible, multithreaded, garbage collector technology is designed specifically to support critical embedded systems. Contrary to general consensus, it does not use copying or compaction, it does not fragment, and it is deterministic with the ability to do worst-case-execution-time analysis. As has been noted elsewhere in this thread, and is well documented, memory management is only one aspect of deterministic and safety critical systems. We address many other aspects as well.
Our products specifically are targeted at safety critical applications. We believe that it is safer to use a program language and runtime environment that eliminates pointer arithmetic errors, program stack errors, null pointer errors, memory leaks and similar errors, than a so-called “stronger” system level language that includes direct pointer manipulation and programmer controlled memory freeing. We also believe that static analysis plays an important role in good software development practices and results in more reliable programs.
I know there is a lot of disbelief out there, but our technology is not new. We have been an operating business for over 10 years. There are 10′s of thousands of devices using our products. It may be a question of personal choice whether to use C/C++ for safety critical and realtime systems or not. But, if someone wants to explore using Java as an alternative that eliminates the type of memory related mistakes I just mentioned, to reduce their development time and increase the reliability of their code, I would encourage that person to review the technical papers on our website, and to contact me directly for further information, and to obtain a personal edition license of our products.
My apologies for the blatant product pitch, but I am responding to what I perceive as misinformation that directly contradicts some of the exact reasons our company, aicas, was founded.
my contact info: David Beberman, dbeberman@aicas.com.

]]>

By: D. @ LI

D. @ LI — 2011年11月21日 16:01:18 +0000

I would strongly recommend against using dynamic memory allocation in C or C++ embedded systems other than in the initialization phase. The reason is memory fragmentation, which isn’t so much of a problem in PC applications with virtual memory available, but is a killer in long-running embedded systems. Memory leaks can also be difficult to eliminate completely in complex C systems.

For non-critical embedded systems without hard real-time requirements, Java (or C# on a Microsoft platform) may be more suitable. These languages provides copying garbage collectors, which avoid fragmentation (provided you don’t allocate and free large objects) as well as memory leaks.

]]>

By: M. @ LI

M. @ LI — 2011年11月21日 16:00:58 +0000

Most of my embedded experience has been with safety critical embedded applications, such as air data computers, navigation, and defense systems. In such applications, it is common practice to avoid dynamic memory allocation because of the high cost of testing and certification. A memory leak in an air data computer could cause an aircraft to lose its airspeed, altitude, and similar information. So dynamic allocation is avoided to insure that the resulting system in testable and predictable. This does not mean that all embedded applications cannot use dynamica allocation. If I was doing a consumer product with a simple GUI application, I would prefer using an OO system and most of those have libraries which use dynamic memory allocation. I have not had to write any embedded applications which demanded dynamic memory allocation for any systems yet.

]]>