Re: MT allocator?

[Stefan Olsson <stefan at noname4us dot com>]

Phil Edwards wrote:

> > 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?
Short answer: Unwanted behavior since this leads to large amounts of 
unused allocated memory over time.


> > 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...
:) I agree. What would be a really "nice to have" feature in the 
pthread_alloc is a way of defining this behavior (return freed memory to 
thread specific free list or global).


> > 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).
Ok...
...that's actually "fine" as long as the current approach/decision is 
made clear to the developers. What do I mean? Well, as things are right 
now (clearly these my humble thoughts on the subject) the 
"responsibility" for memory management is unclear.

Should for instance the STL have a memory management of it's own or 
should it rely fully upon the malloc() call provided by the OS? Writing 
MT applications using STL right now kind of implies the use of 
malloc_alloc which is working Ok - though not optimal - on for instance 
Linux which keeps thread specific free lists. However doing the same on 
other platforms will yield a completely different result, and in any 
case using this approach will make it very hard to improve locality down 
the road (this obviously applies to both MT and non MT applications).

I would say that implementing [thread] optimized memory management into 
STL is a must and thus minimizing the amounts of malloc() calls placed 
to the OS (and ofcourse make sure that we are only requesting full pages 
of memory and so on...). This way we should be able to get similar 
performance on all platforms as well as improve locality.

I don't know if this is the time or place to have this discussion, but I 
do believe that there is a need for it and that there are a lot of 
things that can be done without violating the standard!

Brgds

/Stefan

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

This person must be fired.