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