[!] Pthread-specific node allocator. Storage leak?

[Nathan Myers]

George T. Talbot wrote:
> // Pthread-specific node allocator.
> // This is similar to the default allocator, except that free-list
> // information is kept separately for each thread, avoiding locking.
> // This should be reasonably fast even in the presence of threads.
> // The down side is that storage may not be well-utilized.
> // It is not an error to allocate memory in thread A and deallocate
> // it in thread B.  But this effectively transfers ownership of the
> // memory, so that it can only be reallocated by thread B.  Thus this
> // can effectively result in a storage leak if it's done on a regular
> // basis. It can also result in frequent sharing of cache lines among 
> // processors, with potentially serious performance consequences.
> 
> ...  If I use a queue<T> as a queue operations for a thread, 
> it'll leak, and, in fact, this happens and is a
> problem in practice.

This is a very serious problem.  It is most serious for basic_string<>
because there is no way to fix it at the user level.  It needs to be
fixed in the library.
 
> I guess there's no way to implement this so it doesn't leak short of a
> shared free list, right?  That would imply locking on every operation, 
> which is probably bad.

There are intermediate approaches.  Locking on every allocation would
be bad, but leaking is worse.
 
> For now, how do I work around this if I've got a program that has a
> producer and a consumer that use:
> 
> Queues
> Strings
> Vectors
> etc.

You really need to use a different allocator, at least for 
basic_string<>.  That means supplying a different underlying 
implementation of std::allocator<>, not substituting a different
_Alloc argument.  For queues and vectors you can control which 
thread allocates the storage, and deallocate in the same thread.
That's a nuisance to implement, and may be more expensive than 
a per-allocation/per-free lock.

libstdc++-v3 won't be ready for production use in multithread
environments until work on a better allocation regime is done.

Nathan Myers
ncm at cantrip dot org