Comments on: Free store is not free lunch http://embeddedgurus.com/state-space/2010/01/free-store-is-not-free-lunch/ A Blog by Miro Samek Tue, 08 May 2012 09:20:07 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Peter Bushell http://embeddedgurus.com/state-space/2010/01/free-store-is-not-free-lunch/comment-page-1/#comment-9378 Peter Bushell Tue, 19 Jul 2011 08:26:57 +0000 http://embeddedgurus.com/state-space/2010/01/29/free-store-is-not-free-lunch/#comment-9378 Actually, fragmentation was acknowledged as a problem in Miro's previous post: "A Heap of Problems", so my assertion that it had been ignored applies only to this article, which is a bit parochial of me. Sorry about that! Actually, fragmentation was acknowledged as a problem in Miro’s previous post: “A Heap of Problems”, so my assertion that it had been ignored applies only to this article, which is a bit parochial of me. Sorry about that!

]]> By: Peter Bushell http://embeddedgurus.com/state-space/2010/01/free-store-is-not-free-lunch/comment-page-1/#comment-9376 Peter Bushell Tue, 19 Jul 2011 08:21:20 +0000 http://embeddedgurus.com/state-space/2010/01/29/free-store-is-not-free-lunch/#comment-9376 Apart from the timing uncertainty inherent in using a heap, there is the issue of fragmentation, leading, effectively, to a progressive reduction in the total memory available for allocation. This is a *very important consideration* in most embedded systems and, as usual, it has been ignored. As John has hinted, it is possible to provide alternative allocation strategies in C++, but this is not just about STL (which I hate, anyway). It is possible to eliminate the heap entirely and to provide per-class pools for those ob jects which are to be allocated dynamically. These, having fixed-size blocks, are immune to fragmentation. Furthermore, fixing the pool sizes at design time and attaching each pool to a specific class limits the scope of memory starvation problems and allows them to be found and fixed more easily. The space overhead for each pool is very low and timings are fast and determinate. Maybe it sounds hard to do all this. Well, designing the necessary templates, etc., took me some time, but they are very easy to use (by simple inheritance) and completely transparent in operation (just use "new" and "delete", as before). I've been quite evangelical about this subject on my blog (link available on the home page of this blog), and my code is available there for download via the "subscribers" page. There's a new, better documented version on its way quite soon. Any comments on my viewpoint - either here or there - greatly appreciated. Apart from the timing uncertainty inherent in using a heap, there is the issue of fragmentation, leading, effectively, to a progressive reduction in the total memory available for allocation. This is a *very important consideration* in most embedded systems and, as usual, it has been ignored.

As John has hinted, it is possible to provide alternative allocation strategies in C++, but this is not just about STL (which I hate, anyway). It is possible to eliminate the heap entirely and to provide per-class pools for those ob jects which are to be allocated dynamically. These, having fixed-size blocks, are immune to fragmentation. Furthermore, fixing the pool sizes at design time and attaching each pool to a specific class limits the scope of memory starvation problems and allows them to be found and fixed more easily. The space overhead for each pool is very low and timings are fast and determinate.

Maybe it sounds hard to do all this. Well, designing the necessary templates, etc., took me some time, but they are very easy to use (by simple inheritance) and completely transparent in operation (just use “new” and “delete”, as before).

I’ve been quite evangelical about this subject on my blog (link available on the home page of this blog), and my code is available there for download via the “subscribers” page. There’s a new, better documented version on its way quite soon. Any comments on my viewpoint – either here or there – greatly appreciated.

]]> By: John Wellbelove http://embeddedgurus.com/state-space/2010/01/free-store-is-not-free-lunch/comment-page-1/#comment-8107 John Wellbelove Mon, 20 Jun 2011 19:59:26 +0000 http://embeddedgurus.com/state-space/2010/01/29/free-store-is-not-free-lunch/#comment-8107 "For example, most standard C++ libraries (e.g., STL, Boost, etc.) requrie the heap. Without it, C++ simply does not feel like the same language." It's possible to create alternate allocators for STL. I recently published an article on Codeguru decribing an allocator that takes its resources from the stack, so that STL containers can be used as local variables in functions, without touching the heap at all. “For example, most standard C++ libraries (e.g., STL, Boost, etc.) requrie the heap. Without it, C++ simply does not feel like the same language.”

It’s possible to create alternate allocators for STL. I recently published an article on Codeguru decribing an allocator that takes its resources from the stack, so that STL containers can be used as local variables in functions, without touching the heap at all.

]]> By: Tad huskie http://embeddedgurus.com/state-space/2010/01/free-store-is-not-free-lunch/comment-page-1/#comment-54 Tad huskie Sat, 03 Apr 2010 13:08:04 +0000 http://embeddedgurus.com/state-space/2010/01/29/free-store-is-not-free-lunch/#comment-54 Right, regarding no 4., I used to meet this issue. Once as in writing some code into a pic, I tried putting code into an interrupt service routine, the result in simulator informs that so lots of stack overflow and underflow, I hadn't figured it out until moving all code out of ISR, just using some bit as flags in that, and it did really work. So as a rule of thumb, ISR is very sensitive, as little code using the heap as possible! Right, regarding no 4., I used to meet this issue. Once as in writing some code into a pic, I tried putting code into an interrupt service routine, the result in simulator informs that so lots of stack overflow and underflow, I hadn’t figured it out until moving all code out of ISR, just using some bit as flags in that, and it did really work. So as a rule of thumb, ISR is very sensitive, as little code using the heap as possible!

]]>