{"id":6874,"date":"2014-05-06T10:32:56","date_gmt":"2014-05-06T09:32:56","guid":{"rendered":"https:\/\/blogs.mentor.com\/colinwalls\/?p=6874"},"modified":"2026-03-26T16:43:16","modified_gmt":"2026-03-26T20:43:16","slug":"dynamic-memory-in-real-time-systems-a-solution","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/embedded-software\/2014\/05\/06\/dynamic-memory-in-real-time-systems-a-solution\/","title":{"rendered":"Dynamic memory in real time systems – a solution?"},"content":{"rendered":"

C++ has been on my mind lately<\/a>. There are many reasons why embedded developers are wary – possibly even afraid – of C++. These include code bloat, execution performance and unreliability resulting from dynamic memory allocation. They are all issues with which engineers should concern themselves, however, none of them are intrinsic problems with the C++ language, as they can all be controlled and contained.<\/p>\n

The last on this list of concerns – dynamic memory allocation – I find particularly interesting …<\/p>\n

In broad terms, I would say that dynamic allocation of memory in a real time system is a very bad idea. This is for two key reasons, both associated with the standard allocation function malloc()<\/strong>. First, an allocation call is non-deterministic – never good news when predictability of performance is a key requirement. Second, an allocation request may fail in a somewhat unpredictable manner. This is because of heap fragmentation – there is plenty of free memory available, but no contiguous block is large enough for a given request. In this example, there is 6K of free memory, but a request for a block larger than 3K will fail.<\/p>\n

\"Image\"<\/a><\/p>\n

I have written about this here<\/a> before and, in more detail, in a white paper<\/a>.<\/p>\n

Of course, there is a solution. Just about every real time operating system [RTOS] around provides facilities for the deterministic allocation of fixed size memory blocks. You simply set up a “pool” of blocks during initialization and request and release blocks as required. The allocation time is predictable and the failure mode well defined and controlled. Of course, fixed size blocks sound restricting, but that is not the case for many types of application. If you really want to have something that looks like malloc()<\/strong>, you can easily write one. All that is needed is a set of memory pools with exponentially increasing block size. The new allocation function simply requests a large enough block from the appropriate pool.<\/p>\n

In C++, the new<\/strong> operator essentially hides a call to malloc()<\/strong>, so rewriting this function addresses the issue. Another approach [which I was reminded about this week by Peter Bushell – thanks Peter] can be more efficient. When you instantiate a C++ class [for struct], the new<\/strong> operator is used to allocate space for its data. When you define a class, you can overload new<\/strong> to make it behave in a class-specific way. A good approach is to define a memory pool for each class, with blocks of precisely the required size. The size of the pools [i.e. number of blocks] depends on the usage of the class, but can be determined quite straightforwardly.<\/p>\n","protected":false},"excerpt":{"rendered":"

C++ has been on my mind lately. There are many reasons why embedded developers are wary – possibly even afraid…<\/p>\n","protected":false},"author":71677,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[313,334,300],"industry":[],"product":[],"coauthors":[],"class_list":["post-6874","post","type-post","status-publish","format-standard","hentry","category-news","tag-c","tag-dynamic-memory","tag-embedded-software"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/6874","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/users\/71677"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/comments?post=6874"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/6874\/revisions"}],"predecessor-version":[{"id":10267,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/6874\/revisions\/10267"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/media?parent=6874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/categories?post=6874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/tags?post=6874"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/industry?post=6874"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/product?post=6874"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/coauthors?post=6874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}