[v3] __pool_alloc rework

[Carlo Wood]

On Fri, Jun 18, 2004 at 02:47:25PM +0200, Paolo Carlini wrote:
> >... I was wondering if I can ask for an extension
> >that will more or less stay stable.
> >
> my radical proposal (only for discussion): the original SGI allocator 
> had both a
> MT mode and a non-MT mode (without locks). What about providing now only
> the /latter/, since for MT applications we really want to suggest 
> mt_alloc and the
> performance of pool_alloc are rather poor anyway??
> 
> Paolo.

There is no problem in the non-threaded case: then there are no locks at all.

I am not convinced that a pool allocator has to be poor in performance
in a MT application.

What would help me, and speed up the performance in that case, is if the
pool allocator would be written in a way that the lock that is needed
is not set while calling malloc (new or new[]).  Because
such calls take a long time it would be better for performance too
if the critical area of the allocator would be shortened to a a few lines
of code that actually messes with the pointers that comprise the pool.

If you'd start to call the default allocator (like is used by std::string
for example) mt_alloc in MT case, then that doesn't change anything for my
problem: I'd still need to know if the current thread holds the lock or
the current thread should never hold the lock while calling malloc/new.

-- 
Carlo Wood <carlo@alinoe.com>