[v3] __pool_alloc locking bits

[Benjamin Kosnik <bkoz at redhat dot com>]

This patch just replicates the locking strategy in place in current pool
alloc code, ie single big lock.

Although updates to the patch I'd posted previously pass validation, I
don't think it's right. This would be the multi-lock patch... The
problem is that the base class has static members (_S_start_free,
_S_heap_size, etc) that are modified in the _M_refill and
_M_allocate_chunk members. These are protected in the derived class with
the multi-locks.

The problem is that the derived class is a template, and thus with
multi-locks, allocator<int>::allocate and allocator<char>::allocate are
different code paths. Thus, if both these codepaths are called in
separate threads, with different size allocations, and thus mutexes, we
could have two (or more) threads running through the thread-unsafe base
class bits. So, I think this is a no-go. If I'm wrong, it's easy enough
to pull those bits later.

I'm not quite sure finer-grained locking is possible with the current
shared-pool design in pool_alloc. Since there are clearly superior
alternatives for MT code, and the point with __pool_alloc is to keep a
similar design to the old, default allocator.... I don't see much point
in hacking on this.

tested x86/linux, default/pool_alloc allocators
performance tested

Attachment: p.20040625.patch
Description: Text document