This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MT allocator?


On Sat, Jun 01, 2002 at 12:58:41PM +0200, Stefan Olsson wrote:
> 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.]".

That was sort of a reminder to myself to come back and clean up the
pthread_alloc header mess.  And once that was done, document the result.


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

Right.  Thus pthread_alloc...


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

I'm confused by the last sentence; is that the behavior you want, or the
behavior you don't want?


> 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

That does look interesting, although I'm instinctively frightened by user
code that declares all its stuff inside namespace std...


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

Yep.  From what I've heard, half the C++ community is pressuring the
committee to add threading support, and the other half is pressuring them
to leave it out (because if the committee specifies something stupid,
everyone loses).


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]