apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From E Holyat <ehol...@yahoo.com>
Subject Re: apr_pools and thread safety
Date Tue, 28 Jun 2005 21:16:21 GMT

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

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 <jorton@redhat.com> wrote: On Tue, Jun 28, 2005 at 09:41:36AM -0700, E Holyat
> 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
View raw message