Re: Suggestion for mt_alloc.

[Dhruv Matani <dhruvbird at gmx dot net>]

On Sun, 2004-02-08 at 21:24, Stefan Olsson wrote:
> Dhruv Matani wrote:
> 
> >Why not keep mt_alloc a proper multi_thread allocator ONLY. No ST
> >support, and when __GTHREADS is not defined, use the default pool
> >allocator without thread support.
> >
> Hi Dhruv,
> 
> this can of course be done, but the performance is very close the 
> current default allocator (pool allocator) and is more consistant in 
> it's behaviour than both the default and malloc (at least on Linux). I 
> still believe that it is suitable for ST applications as well.

Yes, but I have been reading a few messages about a few things not
working here and there and also about how the thread_id variavle is
useless for ST apps. I think that even the other pointer is useless
because the default node allocator has a zero byte overhead per block
while the mt_alloc for st_apps would (I believe) have a 4 byte overhed
on my system. So, instead on getting both working with #defines
everywhere, why nbot just concentrate on improving mt_alloc for what
it's meant for which is multi threaded allocation/deallocation, and let
the other allocator (node allocator) hendle what it does best, which is
handle requests for ST apps.


> >Also, one more thing that comes to my mind is that is it possible to
> >provide a Mt_Layer abstraction similar to debug_allocator? So, any
> >allocator can be made simple mt compatible by doing:
> >
> >Mt_Layer<Some_Allocator<Type>, Mutex_Type>?
> >
> >
> >That way, the Locking can be removed from the pool_allocator, and
> >shifted to this layer, so that even if a user provides an ST allocator,
> >and wants basic Mutex locking on allocation/deallocation, it can be done
> >with one line of code?
> >
> I don't quite understand, but it's not simply a global lock on all 
> operations. Much of the performance boost from mt allocator (in real 
> world applications) comes from the fact that each bin is locked 
> individually - if locking is needed at all.

I not talking about the mt_alloc<>. Of course the mt_alloc<> is more
complicated in the locking and stuff. But, for simple ST allocators like
pool_allocator<> with the internal Locking removed, and user supplied
allocator can take advantage of the gthread layer by using this simple
and light weight covering that I have proposed. So, for pure ST apps.,
the unnecessary locking need not be there even in the code. It would
simplify the code maintenance more than anything else, and avoid code
duplication for other allocator that will be written in the future. So,
this layer can provide a very BASIC locking unlike the mt_allocator<>
which is meant specially for MT usage.





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