Re: Policy on rebooting?

From: Peter Bushell (NOpeter.bushell_at_SPAMsoftware-integrity.com)
Date: 10/07/04 

Date: Thu, 7 Oct 2004 14:58:51 +0100

"Michael N. Moran" <mike@mnmoran.org> wrote in message
news:GU99d.179610$Np2.98150@bignews4.bellsouth.net...
> D. Zimmerman wrote:
>>
>> This also depends on the operating system being used. Most real time
>> OS's, which are often used for embedded, will only allocate fixed size
>> memory blocks and will reclaim the entire block. This prevents the
>> problem Paul described.
>
> This does not *prevent* the problem, it only limits/slows the problem
> if the application has a particular pattern of dynamic memory usage.
>
> Imagine a limited supply of large fixed size blocks. If these blocks
> are allocated and released and then subsequently allocated and
> fragmented to fulfill the needs of another part of the system
> requiring a smaller block size (of which there are no more), then
> eventually such an allocation system will fail as well.
>
The fixed-size-block allocation scheme is foolproof unless some fool tries
to circumvent its "shortcomings" by doing the kind of thing you describe
above. The solution is to have the right number of right-sized pools
containing the right number of right-sized blocks (as you say below) - but
with *no poaching allowed*. If you can't get the proper-sized block, then
there aren't enough, so back to the drawing board. Stealing a bigger block
from another pool (transparently or not) is not acceptable; it just
re-introduces fragmentation by the back door.

> Of course, we're talking about general malloc/free new/delete here,
> not private memory pools, which are pre-allocated for a particular
> part of the system with fixed sized blocks.
>

I agree wth eschewing malloc() and free(). However, if you want to use C++
effectively in an embedded system, you really have to customise new() and
delete() to use a safe, fixed-size-block scheme tailored to your system.
This is painful, but essential. It is very hard to use C++ effectively
without using new() and delete().

> What's more is that block memory allocation schemes reduce the
> "memory efficiency" advantages of dynamic memory allocation by
> wasting the unused portion of each allocated block.
>
True, but better that than the indeterminacy of fragmentation.

> BTW, allocation is not the issue. If memory is never freed,
> then fragmentation will not happen. Of course, then its not
> *really* dynamic.
>
Also true, and not as daft as it sounds. Using such a "heap" is quite a
convenient way of initially allocating pools, stacks, etc. 

-- 
--
Peter Bushell
http://www.software-integrity.com/

Relevant Pages

  • Re: How to release heap memory that is marked as free
    ... As I said, fragmentation is a very serious problem, and one of the most serious problems ... my allocator was accused of using massive amounts of memory. ... I'm going to have to re-think the memory allocation that I'm ... process's 'working set'. ...
    (microsoft.public.vc.mfc)
  • Re: CMemoryState & multi-threaded application
    ... released, and interspersed with smaller allocations, *will* cause fragmentation. ... I've sometimes done this by having a thread that wakes up once a minute and traces memory. ... Manager, Process Viewer, etc., since they are largely clueless about storage allocation ...
    (microsoft.public.vc.mfc)
  • Re: Policy on rebooting?
    ... if the application has a particular pattern of dynamic memory usage. ... What's more is that block memory allocation schemes reduce the ... then fragmentation will not happen. ...
    (comp.arch.embedded)
  • Re: Memory leak with CAsyncSocket::Create
    ... socket is properly closed and deallocated between calls. ... memory creep in my system. ... because this is really indicating fragmentation (I suppose you ... many levels of allocation going ...
    (microsoft.public.vc.mfc)
  • Re: Memory leak with CAsyncSocket::Create
    ... socket is properly closed and deallocated between calls. ... memory creep in my system. ... fragmentation issues, but that's about the only value it has: ... many levels of allocation going ...
    (microsoft.public.vc.mfc)