MT allocator?

Stefan Olsson stefan@noname4us.com
Sat Jun 1 04:00:00 GMT 2002


Hi!

I raised a similar question to this one to the list late last year, but 
would like to get your input on the following:

In the documentation under "Available allocators in namespace std" there 
is a note "[Another threadsafe allocator where each thread keeps its own 
free list, so that no locking is needed, might be described here.]".

Is anybody working on such an allocator? The issue with the default 
allocator in a threaded enviorment is as you know that it locks the 
entire heap and therefore seriously degrades the performance (i.e. we 
are doing a lot of string operations, putting strings into vectors and 
maps in each thread etc).

However we cannot use the pthread_alloc implementation (from SGI) since 
we are also maintaining an application wide hash_map of objects for 
caching purposes (i.e. when one thread has completed a specific request, 
that result is copied into the hash_map and when another thread modifies 
data that was part of building the cached result this record is removed 
from the cache by that thread). This means that the thread deleting 
objects from the hash_map will take ownership for that memory...

The only solution at this stage for us has been to use 
std::__malloc_alloc_template< 0 >, but this puts a lot of load onto the 
OS and fragmentation is an issue as well as performance degradation.

One solution would be to have both global and thread specific free 
lists, such as the implementation at 
http://www.bti.net/cgi-bin/bti/show_header.pl?file=bti_thread_alloc.h

When thinking about this, the next question would be how to improve "per 
thread locality" and this is _really_ new stuff to me, but from what I 
have read so far can make a huge difference on MP machines...

I am willing to put effort into doing this, but due to my limited 
knowledge I need a hint of where to begin and to know what already has 
been done :)

Brgds

/Stefan

--
In any organization there will always be one person who knows what is going on.

This person must be fired.




More information about the Libstdc++ mailing list