Suggestion for mt_alloc.

[Stefan Olsson]

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.

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

Brgds

/Stefan

>
>
>
>  
>