Re: [v3] __pool_alloc rework

[Paolo Carlini <pcarlini at suse dot de>]

Carlo Wood wrote:

> There is no problem in the non-threaded case: then there are no locks at all.
>  
I don't understand: I'm talking about __threads == false in the original 
design (that
which shipped with 3.3.x)

> I am not convinced that a pool allocator has to be poor in performance
> in a MT application.
>  
During the last months we posted numbers and there is a whole literature 
about that.

> 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.
;) Of course we are not talking about naming things one way or another. 
We are
talking about *a different* allocator, optimized for MT. The mt_alloc 
indeed, the
one you find in /include/ext/mt_allocator.h. Future developments, 
particularly so
in the area of optimizing the performance for MT, belongs to mt_alloc.

Paolo.