On 20.02.2017 15:55, Jim Jagielski wrote: >> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> >> wrote: >> >>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski <j...@jagunet.com>: >>> >>> The below got me thinking... >>> >>> Right now, the pool allocator mutex is only used when, well, >>> allocator_alloc() is called, which means that sometimes >>> apr_palloc(), for example, can be thread-safeish and sometimes >>> not, depending on whether or not the active node has enough >>> space. >>> >>> For 1.6 and later, it might be nice to actually protect the >>> adjustment of the active node, et.al. to, if a mutex is present, >>> always be thread-safe... that is, always when we "alloc" memory, >>> even when/if we do/don't called allocator_alloc(). >>> >>> Thoughts? >> So, apr_p*alloc() calls would be thread-safe if a mutex is set in >> the underlying allocator? Hmm, at what cost? would be my question. >> > The cost would be the time spent on a lock on each call to apr_palloc() > or anything that *uses* apr_palloc(). > > The idea being that if the underlying allocator has a mutex, the > assumption should be that the pool using that allocator "wants" > or "expects" to be thread-safe... It seems an easy way to create > thread-safe APR pools, but I could be missing something crucial > here. > > Of course, if the allocator does NOT have a mutex, no change and > no cost.
I've always understood that creating subpools is thread safe iff the allocator has a mutex, but allocating from any single pool is not, by definition. Acquiring a mutex for every apr_palloc() seems like a good way to throw away pools' speed advantage compared to malloc(). -- Brane
