Then I think I may be running into an allocator_alloc bug during my testing.  In a tight for loop, I am creating a thread which creates a child pool from the parent.  I am crashing because my child pool is NULL.  I am not sure yet, whether the child pool is reusing an index from the parent or creating a new one.

But I can see the following still holds true for allocator_alloc and allocator_free.  allocator_alloc allows a free read on max_index when either allocator_alloc / allocator_free can change that value.

If 40 threads from the same parent create child pools. 40 threads can fall into the first "if statement". The access within that "if statement" is mutually exclusive, but, if max_index is being decremented within the "if statement", then the condition that put the 13 or 14th or nth thread into that "if statement" may no longer hold true.  Wouldn't that invalidate the index alignment check and give a thread an invalid child pool reference?

The mutex should be moved outside of the if and else if


if (index <= allocator->max_index) { can be changed while being read


/* If we found nothing, seek the sink (at index 0), if

* it is not empty.


else if (allocator->free[0]) { 2 threads can enter.

Joe Orton <> wrote:
On Tue, Jun 28, 2005 at 09:41:36AM -0700, E Holyat wrote:
> I assumed that pools were thread safe.
> Is apr_palloc intended to be thread safe within a pool object?

No - for a given pool, creation of subpools is a thread-safe operation,
but not allocation of memory.



Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football