Home > Dynamic memory allocation, Projects, RTOS, SKC++ > SKC++ and Dynamic Memory

SKC++ and Dynamic Memory

Monday, September 14, 2009 Leave a comment Go to comments

Today’s post is about the strategy of dynamic memory handling in SKC++.

Last time, I recommended a short slide presentation for perusal. I will not repeat here what that says, except to quote the last slide:

Preventing fragmentation
• Always use pools, never heaps
– Exception: memory which is never intended to be freed can be taken from a heap
• Override the global new() and delete() operators
• Consider per-class new() and delete() operators
– Quicker, as well as safer

In a nutshell, that is the strategy for SKC++.

Firstly, I consider the global functions operator new and operator delete, which are overridden. They need to be overridden anyway because the versions supplied with a typical compiler are not re-entrant and do not provide the locking mechanisms which are required in a multitasking system, but which depend upon the kernel in use for their implementation.

Secondly, I look at the principles of overriding the corresponding operators in each class where dynamic allocation and freeing of objects (using pools) is needed.

::operator new

SKC++ overrides this global function to provide an “allocate-only” heap. This quasi-heap serves only to provide a source of raw memory for SKC++ and for the application. Some of this memory will be used to form pools, which do the real dynamic memory handling, using blocks of fixed size. Because no memory acquired from the quasi-heap is ever returned to it, there is no need for elaborate management of the quasi-heap; simply handing out a pointer, on allocation, then moving the pointer along, for next time, will do – with proper locking during this operation, of course.

::operator delete

As nothing is ever returned to the global quasi-heap, this global operator should never be used. All “real” allocation is done via pools, using per-class operators (see below). Any call to the overriden global operator delete will therefore cause a fatal error. Incidentally, a mistake of this kind in SKC++ is trapped as an assertion failure. There is no point attempting run-time recovery from a blatant conceptual error; it should be discovered and fixed during development. There will be more on error-handling in another post.

::operator new[] and ::operator delete[]

These operators are problems waiting to happen. As with the global operator delete, these are overridden to cause fatal errors, if called. This is enough to catch any careless use of the hateful new[] and delete[] constructs anywhere in the program, so there is no need to consider per-class overrides for these operators.

SomeClass::operator new and SomeClass::operator delete

In an OO system we need pools of objects, not just pools containing general-purpose memory blocks. Therefore, pool management, for any particular group of objects which requires it, should be incorporated in the class defining those objects. For the user, it should be necessary only to use the normal new and delete facilities of C++, the details being taken care of by specialised operators in the class.

SKC++ adopts this principle. Unfortunately, because of the way these operators work within the class structure in C++, it is not possible for SKC++ to take on the complete responsibility for the integrity of pool handling throughout the entire system by, for example, subsuming all operator new and operator delete overrides into a comprehensive set of base classes. SKC++ does its best to ease the burden of the programmer with regard to SKC++ objects by applying this and other techniques (and certain compromises) within the limitations of C++, but in some cases, especially for classes unrelated to SKC++, the proper dynamic handling of objects remains squarely the programmer’s responsibility. SKC++ does help a little, here, by making available the Pooled class (described in a later post) which is used in the kernel.

The tactics and details are better explained with reference to the actual SKC++ classes which support object pools, so I will return to this subject piecemeal as the relevant classes come up for discussion.

Advertisements
  1. Peter Bushell
    Thursday, October 1, 2009 at 09:07

    Update…

    Having now coded the Pooled class, I have realised that it does, in fact, provide everything needed to add dynamic memory allocation facilities to any class, according to SKC++ principles, without pain for the user. I am surprised that it worked out so well and so simply!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: