Re: [boost] Re: Query of Interest - vlarray

From: hicks (hicks_at_[hidden])
Date: 2002-04-17 12:29:54

Re: Query of Interest - vlarray

As far as I understand, the desired behavior is a fast allocator.
Allocation always occurs at the end of the stack,
or to put it another way, just beyond the highest block of currently
allocated memory.
Because you intend to only allocate to temporary variables,
(voluntary compliance), the highest block of currently
allocated memory and the most recently allocated block of
memory will (should) be the same.
Supposing that the LIFO (most recently allocated,
next to be freed) assumption is dropped
since voluntary compliance may be violated.
Instead, keep a freed bit for each allocated block.
On deallocation, move the stack pointer only if the freed block
is the last block, otherwise mark it free. If the stack pointer is moved,
move it all the way down to the end of the last non-free block.
The management time barely changes.
Memory might run out, but a fatal error won't occur.

Back to the issue of multithreading.
In a multithreaded application, or a single threaded application linked
to a multithreaded
library supporting new, the call to new incurs a mutex (or whatever)
overhead.
Which is the bigger loss, the mutex call or the allocation strategy
overhead?

Craig Hicks