Suggestion for mt_alloc.

[Stefan Olsson]

Dhruv Matani wrote:

>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.
>
Yes and no. I personally still believe that mt allocator does a better 
job than pool allocator if you start looking at fragmentation over time 
etc. I agree - there are cases when mt allocator is slower and pool 
allocator faster - and there are and will be cases with quite opposite 
results.

There is no silver bullet. I think what we need to do is to provide some 
guidelines for users on how to write code so that they simply can test 
out various allocators (maybe we need to put some limit on the number of 
allocators that we can maintain/support but anyway) in their specific 
real world application - that's the only place that counts!

I.e. provide example #defines of the standard containers which could be 
included in one global header file throughout a project.

>
>
>  
>
>>>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.
>
Ok, I get the idea...
...but I believe that a "#ifdef solution" will give the same results and 
minimize the amount of code to maintain. I.e., add a couple of #ifdef 
__GTHREADS and if (__gthread_active_p()) (which is evaluated at compile 
time) to pool allocator and you're done!

Brgds

/Stefan