[cap-talk] Memory allocation in embedded systems

[David Hopwood]

Jonathan S. Shapiro wrote:
> On Tue, 2007-01-02 at 00:58 +0000, David Hopwood wrote:
> 
>>If C had a general-purpose pool allocator in its standard library, I might
>>have used that, but it doesn't.
> 
> David: are you aware of umem, which is a malloc replacement based on the
> slab allocator? The slab allocator definitely qualifies as a pool-based
> allocator.

umem would be overkill for any of the applications I've written so far, in
which only a single thread allocates out of each pool. Thanks for the
suggestion, though; I will bear it in mind for other projects (not necessarily
embedded).

> If this is of interest, let me know offline and I will ask Jonathan
> Adams (the author) if the umem allocator is available under sensible
> terms. I'm pretty sure it has been released under Sun's community source
> license, but it is conceivable that they released it under BSD.

The Sourceforge project is released under the "Common Development and
Distribution License"
(http://umem.cvs.sourceforge.net/umem/umem/OPENSOLARIS.LICENSE?revision=HEAD&view=markup),
which is one of these excessively long open-source licences drawn up by
corporate lawyers, but does not appear to contain anything particularly
objectionable.

> I'ld also draw your attention to the kmalloc() that was widely used in
> UNIX kernel prior to the publication of the slab allocator. In most
> implementations, kmalloc() takes a pool name as an additional argument.
> kmalloc() is certainly available under a BSD copyright.

kmalloc is also overcomplicated for my purposes. I would spend more time
verifying that it is correct (if it is), than I would to rewrite/verify
something with the same functionality.

>>There is an obvious objection to this argument, which is that given a fixed
>>total amount of memory, the *first* allocation failure of a system that takes
>>memory from multiple separate, statically sized pools, will occur before that
>>of a system that takes memory from a common pool. However, when the first
>>allocation failure occurs is not the point. In a well-written embedded or
>>safety-critical application (or in an OS kernel), you always have robust error
>>handling of any possible resource exhaustion situation. Failure of an allocation
>>attempt is not a problem as long as it occurs at a point where you can recover
>>correctly.
> 
> This is equally true in a conventional heap-based implementation. The
> real issue is slightly more subtle. [You do this for a living, so please
> pardon my presumption.]
> 
> A pool-based allocator is never subject to fragmentation, which
> completely eliminates an entire class of allocation failures, some of
> which may leave an unrecoverable system.

Right. I did mention fragmentation briefly in my previous post, but perhaps
underemphasized its importance; by itself it would be a showstopper for the
use of malloc.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>