E Holyat wrote:
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
I'll go have a look at this now to see if we really have a race condition.
Moving the mutex has performance implications, so I want to make sure
we actually need to do that.
Thanks for reporting,
Sander
