STL containers and managing memory allocation in embedded systems

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()?


--
 Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978.html
     http://sourceforge.net/users/alexvn

Alex:

When you say 'vector<Foo> v;' actually you are saying:
vector<Foo,allocator<Foo> > v;
because of the default second parameter of the vector template
definition:

template <class T, class Allocator = allocator<T> >
class vector.....

And the member allocate() of allocator "...Throws the exception
bad_alloc if the storage is unavailable. This function uses operator
new(size_t)..."

Hope this help.

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.

If you can't afford to allow exception handling, you generally can't
allow C++ style dynamic memory handling.  It's as easy as that.

> How can one manage that?

Primarily by not doing it.

> 2. But how to manage memory allocation in containers for embedded
> systems?

Primarily by not using them.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 31 Mar 2006 13:32:07 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> 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.
>
>If you can't afford to allow exception handling, you generally can't
>allow C++ style dynamic memory handling.  It's as easy as that.
>
>> How can one manage that?
>
>Primarily by not doing it.
>
>> 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.

The main problem is that *every* allocation must be checked, wheteher
with exceptions or with null pointer return.

I am now working on one embedded system, and it *must* use some kind
of memory management, so as to balance resources between different
parts of the program. As I am compiling with GCC, exception throwing
is a definite no-no, becuase it neraly doubles the space used by code.

But everything works fine by using no-throw new operator and checking
its result. BTW, I am also making some test on using STL allocators to
optimize some parts of the system, spceially the multhreaded C++
kernel.

Zara

"Alex Vinokur" <alexvn@users.sourceforge.net> wrote in message news:1143807347.615801.203800@t31g2000cwb.googlegroups.com...
[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

size_t the_size = v.size();
Foo f;
v.push_back (f);

if (v.size() != (the_size + 1))
{
   cerr << "Unable to allocate memory via push_back()" << endl;
}


-- 
 Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978.html
     http://sourceforge.net/users/alexvn

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.

Of course, the parts that ARE critical will be designed such that no
memory allocation ever fails.

> > 2. But how to manage memory allocation in containers for embedded
> > systems?
>
> Primarily by not using them.

Used to be true for 512 byte, single function embedded systems. Doesn't
matter so much for 512 Megabyte systems today, where the critical
functions need 200 Mb max.

Remember: even on real-time systems, being faster may be useful, and
using
dynamically allocated memory is a good way to achieve that (e.g. for
caches)

HTH
Michiel Salters

Alex Vinokur wrote:
> By the way, is this check correct?
>
>
> vector<Foo> v;
> // Stuff
>
> size_t the_size = v.size();
> Foo f;
> v.push_back (f);

The standard behaviour when any memory allocation fails is to throw a
std::bad_alloc exception, so if push_back needs to allocate but is
unable, you don't get to the code below at all.

> if (v.size() != (the_size + 1))
> {
>    cerr << "Unable to allocate memory via push_back()" << endl;
> }

Gavin Deane

Gavin Deane wrote:
> Alex Vinokur wrote:
> > By the way, is this check correct?
> >
> >
> > vector<Foo> v;
> > // Stuff
> >
> > size_t the_size = v.size();
> > Foo f;
> > v.push_back (f);
>
> The standard behaviour when any memory allocation fails is to throw a
> std::bad_alloc exception, so if push_back needs to allocate but is
> unable, you don't get to the code below at all.
>
> > if (v.size() != (the_size + 1))
> > {
> >    cerr << "Unable to allocate memory via push_back()" << endl;
> > }
>
> Gavin Deane

if I would like to restrict size of some objs (ex. vector<string>)
what can I do?
rewrite the allocator? is there any shortcut?

Gavin Deane wrote:
> Alex Vinokur wrote:
> > By the way, is this check correct?
> >
> >
> > vector<Foo> v;
> > // Stuff
> >
> > size_t the_size = v.size();
> > Foo f;
> > v.push_back (f);
>
> The standard behaviour when any memory allocation fails is to throw a
> std::bad_alloc exception, so if push_back needs to allocate but is
> unable, you don't get to the code below at all.

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;
> > }

[snip]

Alex Vinokur
     email: alex DOT vinokur AT gmail DOT com
     http://mathforum.org/library/view/10978.html
     http://sourceforge.net/users/alexvn

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.