Pthread-specific node allocator. Storage leak?

[George T. Talbot]

I am assuming that if I pass --enable-threads=posix that I'll get the
allocator from pthread_allocimpl.h, right?

>From stl/bits/pthread_allocimpl.h:

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

Not to be too much of a pedant here, but in a producer/consumer situation,
this is what threads are going to do.  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.

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.

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.

--
George T. Talbot
<george at moberg dot com>