On Fri, 31 Mar 2006 16:39:46 +0200, Zara <yozara@terra.es> wrote:>On 31 Mar 2006 13:32:07 GMT, Hans-Bernhard Broeker ><broeker@physik.rwth-aachen.de> wrote:>>> 2. But how to manage memory allocation in containers for embedded >>> systems? >> >>Primarily by not using them. > >Seems too radical. > >An embedded system may use perfectly dynamic memory as long as it is >able to recover from lack of memory or,at least, not enter an unstable >state. Some Denial-Of-Sservice may be allowed as long as the whole >system continues to work.So you need at least two separate dynamic memory areas, one that can overflow, the other that can't.>The main problem is that *every* allocation must be checked, wheteher >with exceptions or with null pointer return.And what do you realistically do when you detect this condition ? IMHO, it is a bad design if you end up in this situation. In a single task environment you might even be able to unwind some less important allocations (provided that unwinding does not itself use dynamic memory :-), but how do you expect to do anything useful in a multitasking environment with a shared dynamic memory ? In practice, usually the only realistic thing to do, when even a small allocation fails is to restart the system, which in several cases is a severe malfunction. Paul
STL containers and managing memory allocation in embedded systems
Started by ●March 31, 2006
Reply by ●March 31, 20062006-03-31
Reply by ●March 31, 20062006-03-31
Alex Vinokur wrote:> "Alex Vinokur" <alexvn@users.sourceforge.net> wrote in message > [snip] > > 2. But how to manage memory allocation in containers for embedded > > systems? > > > > For instance, > > vector<Foo> v; > > Foo f; > > v.push_back(f); > > > > push_back() returns no values. > > > > So, how can we know (except try-catch) that it is impossible to > > allocate the requested memory in push_back()? > > > [snip] > > By the way, is this check correct? > > vector<Foo> v; > // Stuff... snip ... If you are worried about memory and bloat, why are you using C++ in the first place? -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by ●March 31, 20062006-03-31
Michiel.Salters@tomtom.com wrote:> Hans-Bernhard Broeker wrote: >> In comp.arch.embedded Alex Vinokur <alexvn@users.sourceforge.net> >> wrote: >> >>> The memory allocation issue in embedded systems is usually >>> critical.. >> >> It's usually beyond critical --- it's inacceptable, period. An >> embedded system has nobody to complain to if an operation as >> strictly internal as a memory allocation fails. So it had better >> not go there at all. > > > That's a bit overkill - not all embedded systems are 100% > mission-critical. I.e. you might have a system logger, a > configuration deamon etcetera. Sure, it would be annoying if they > failed, but the watchdog can restart them once the critical parts are > done using all memory.Sure, as long as your customers don't mind an ocassional unexpected reboot. ;-) Noone dies, but my company and I gain a less than desirable reputation. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●April 1, 20062006-04-01
Alex Vinokur wrote:> The memory allocation issue in embedded systems is usually critical.. > > How can one manage that? > > 1. Via 'new' > char* p = new (nothrow) char [SOME_SIZE]; > if (p == 0) > { > // He we know that it is impossible to allocate the requested memory > // We can do something relevant. > } > > > 2. But how to manage memory allocation in containers for embedded > systems? > > For instance, > vector<Foo> v; > Foo f; > v.push_back(f); > > push_back() returns no values. > > So, how can we know (except try-catch) that it is impossible to > allocate the requested memory in push_back()? >The only save way if you disable exceptions is to provide your own allocator and assert. -- Ian Collins.
Reply by ●April 1, 20062006-04-01
Maxim Yegorushkin wrote:> Alex Vinokur wrote: > > > Green Hills' Extended Embedded C++ compiler enables the user to cancel > > exception handling. In this case, can the code below work? Does anybody > > have such experience? > > > > > > > > > if (v.size() != (the_size + 1)) > > > > { > > > > cerr << "Unable to allocate memory via push_back()" << endl; > > > > } > > The standard containers do not provide any guarantees for your case. > Create and use your own containers that do.Or own allocators for STL containers? Alex Vinokur email: alex DOT vinokur AT gmail DOT com http://mathforum.org/library/view/10978.html http://sourceforge.net/users/alexvn
Reply by ●April 1, 20062006-04-01
"Michael N. Moran" wrote:> Michiel.Salters@tomtom.com wrote: >> Hans-Bernhard Broeker wrote: >>> Alex Vinokur <alexvn@users.sourceforge.net> wrote: >>> >>>> The memory allocation issue in embedded systems is usually >>>> critical.. >>> >>> It's usually beyond critical --- it's inacceptable, period. An >>> embedded system has nobody to complain to if an operation as >>> strictly internal as a memory allocation fails. So it had better >>> not go there at all. >> >> That's a bit overkill - not all embedded systems are 100% >> mission-critical. I.e. you might have a system logger, a >> configuration deamon etcetera. Sure, it would be annoying if they >> failed, but the watchdog can restart them once the critical parts >> are done using all memory. > > Sure, as long as your customers don't mind an ocassional > unexpected reboot. ;-) > > Noone dies, but my company and I gain a less than > desirable reputation.Why do you assume a reboot? The failure of a malloc can simply mean postponing that particular operation until later. The important thing is not to assume success. Another option is to perform the mallocs on system initiation. They can handle variable length arrays, for example, which the usual suspects cannot. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by ●April 1, 20062006-04-01
On Sat, 01 Apr 2006 09:34:18 -0500, CBFalconer <cbfalconer@yahoo.com> wrote:>"Michael N. Moran" wrote:>> Sure, as long as your customers don't mind an ocassional >> unexpected reboot. ;-) >> >> Noone dies, but my company and I gain a less than >> desirable reputation. > >Why do you assume a reboot? The failure of a malloc can simply >mean postponing that particular operation until later. The >important thing is not to assume success.This may be realistic option, say, with a fixed size memory pool maintained by the application, in which you can easily implement warning limits at e.g. 90 %, but definitively not with malloc, in which you do not get the warning, until the bad thing happens.>Another option is to >perform the mallocs on system initiation. They can handle variable >length arrays, for example, which the usual suspects cannot.Sure, I use "malloc" in critical applications, but never use "free" and the system runs happily for years without a reboot :-). If the system fails to start due to lack of memory, it is better that the person who performed the reboot is present and might be able to rectify the problem (e.g. by returning to the old functional configuration) rather than having a fatal error at random time within a few months or years e.g. due to dynamic memory fragmentation. Paul
Reply by ●April 1, 20062006-04-01
"Paul Keinanen" <keinanen@sci.fi> wrote in message news:fo7t22pi5l2ud0ngm4vkdsbn4onlh87rce@4ax.com...> > If the system fails to start due to lack of memory, it is better that > the person who performed the reboot is present and might be able to > rectify the problem (e.g. by returning to the old functional > configuration) rather than having a fatal error at random time within > a few months or years e.g. due to dynamic memory fragmentation.That's the point, really. It's not that malloc/free are evil - it's memory fragmentation that's evil, and can cause (or, given time, *will* cause) malloc to fail. What's needed, of course, is a hardware heap manager which separates logical memory blocks from real memory blocks, and actively disallows fragmentation ;). Steve http://www.fivetrees.com
Reply by ●April 1, 20062006-04-01
Steve at fivetrees wrote:> "Paul Keinanen" <keinanen@sci.fi> wrote in message >> >> If the system fails to start due to lack of memory, it is better >> that the person who performed the reboot is present and might be >> able to rectify the problem (e.g. by returning to the old >> functional configuration) rather than having a fatal error at >> random time within a few months or years e.g. due to dynamic >> memory fragmentation. > > That's the point, really. It's not that malloc/free are evil - > it's memory fragmentation that's evil, and can cause (or, given > time, *will* cause) malloc to fail. > > What's needed, of course, is a hardware heap manager which > separates logical memory blocks from real memory blocks, and > actively disallows fragmentation ;).Now you are talking about the quality of the malloc implementation, not its use. Of course you can get in trouble by blindly using features without understanding what goes on. But you usually have several courses of action available: You can postpone some actions when the needed malloc fails. You can keep your own track of possibly freeable candidates, do so, and try again. You can build some sort of memory pool, control its use, and let some background process continuously defrag it. I had such a system running for over three years, until a power failure caused it to reboot. All these things normally involve giving up some measure of portability. However optimizing memory usage can make a process feasible on the given hardware. Fragmentation will not necessarily ever cause failure. A decent malloc will put back together any freed blocks, and once all allocated blocks are freed there is NO fragmentation left. However if your code is faulty, and you have memory leaks, that is another tale entirely. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by ●April 2, 20062006-04-02
CBFalconer wrote:> "Michael N. Moran" wrote: >> Michiel.Salters@tomtom.com wrote:[snip]>>> Sure, it would be annoying if they failed, but the watchdog can >>> restart them once the critical parts are done using all memory. >> >> Sure, as long as your customers don't mind an ocassional unexpected >> reboot. ;-) >> >> Noone dies, but my company and I gain a less than desirable >> reputation. > > Why do you assume a reboot?Note the quoted statement about a watchdog at the top. IMHO, watchdog == reboot.> The failure of a malloc can simply mean postponing that particular > operation until later.Two problems with malloc/free and relatives, is knowing "when" or "if" the memory will become available. *When* must be solved by polling (yuk.) *If* is unknowable in systems where heap fragmentation is possible. I hate non-deterministic stuff in my systems.> The important thing is not to assume success.True for any function that can return an error. In general, it's a "Good Thing" [tm] to limit these types of functions where practical.> Another option is to perform the mallocs on system initiation.Yup. Pre-allocation is good. Only when you use "free" and friends does heap-fragmentation become an issue. [I'm getting that deja-vu feeling about this thread.]> They can handle variable length arrays, for example, which the usual > suspects cannot.I'm out-of-sync with respect to "they". I guess you mean malloc at system initiation, to which I say ... yep. Malloc is a wonderful tool for this type of situation. Obviously, the system documentation and requirements should state the limits so that the customer won't configure a system that fails to operate unexpectedly from lack of memory. cheers, mike -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
