Re: [v3] __pool_alloc rework

[Carlo Wood <carlo at alinoe dot com>]

On Fri, Jun 18, 2004 at 05:02:37PM +0200, Paolo Carlini wrote:
> 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 mean that in the view of my specific problem (thus, not the performance
problem you talk about) the only thing that matters are multi-threaded
applications.  We should only talk about and consider the MT case.

> >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.

Ok

> >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. 

I understood that.  I am looking at this from the point of view of a user,
and then - when the API stays more or less the same and we only consider
multi-threaded applications (see above), then the only thing that changes
from my point of view, as user, is the name of the allocator.

> 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.

But also this allocator sets a lock.  Is this lock set when the allocator
calls operator new in order to allocate more memory?

If so, then is it possible to either change that (only call new at the moment
the lock is not set) ?

.. or provide a public accessor that allows me to see if the current thread
holds the lock *) ?

-- 
Carlo Wood <carlo@alinoe.com>

*) the accessor should return true if the current thread holds the lock, and
can return true if another thread holds the lock more or less at the moment
of the call to the accessor (so, a simple non-atomic test whether or not
the lock is locked from within the accessor suffices: if the current thread
holds the lock then that will always work).