[boost] Re: Re: Re: what happened to allocators in boost?

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-08-26 12:48:00

Peter Dimov wrote:
> Andreas Huber wrote:
>> [snip]
>>> So far my experience indicates that people only bother with
>>> allocators when std::allocator is inadequate, i.e. slow.
>>
>> ... or non-deterministic. Using such an allocator in a hard real-time
>> system is simply not an option.
>> AFAIK, a deterministic allocator must inevitably have a separate heap
>> for each possible object size. The difficult part is reserving enough
>> slots in each heap at startup, before deterministic reaction is
>> necessary. I don't see how a system could do this automatically when
>> memory is scarce.
>
> The usual approach is to borrow an entry from the 2*N heap and split
> it in two when the N heap is empty. [snip]

Which brings back non-determinism, as the 2*N heap could be full also and
thus be borrowing from 4*N already. You can of course guarantee an upper
limit for an allocation, as some heap must have a slot available.
However, for some systems this upper limit is already too slow, so someone
inevitably has to configure heap sizes *before* startup.

> Even if the system allocator does not work for you, why would you
> want to only replace function<>'s allocator but leave all other
> allocations non-deterministic?

Because function objects absolutely have to be allocated during the phase
when a system has to react deterministically. Other objects might be
allocated before this phase.
I guess your hinting at replacing global new/delete, which almost always
works but only almost as Eugene explained.

> And how would the ability help you if
> you want to use a third party library that has signatures of the form
>
> void f(function<void()> const & g);

Yep, no luck here.

[snip]
> I won't even go into details like whether std::allocator's interface
> is suited for the task or whether the function<>'s specification as it
> currently stands gives you any guarantees for deterministic behavior.

I didn't say std::allocator is perfect, but it's standard ;-). function's
spec indeed doesn't guarantee determinism, but I couldn't think of a
reasonable implementation that isn't deterministic.

Regards,

Andreas