[v3] __pool_alloc rework

[Dhruv Matani]

On Sat, 2004-06-19 at 05:48, Carlo Wood wrote:

> > 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 *) ?

How can that be implemented? For the user, the allocate/deallocate
functions will appear as atomic operations, so the lock will never be
held across 2 different function calls.

So, I guess there is no way to know if the *current* thread holds the
lock. However, to know whether other threads hold the lock should be
trivial. Use pthread_mutex_trylock().


Quote:
*) 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).

??? I didn't quite get this last sentence.

-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html