apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject APR pools, mutexes and thread safe allocations
Date Mon, 20 Feb 2017 15:08:21 GMT
Again, this would ONLY happen if the underlying allocator has
a mutex!

> On Feb 20, 2017, at 10:06 AM, Branko ─îibej <brane@apache.org> wrote:
> 
> On 20.02.2017 15:55, Jim Jagielski wrote:
>>> On Feb 20, 2017, at 9:51 AM, Stefan Eissing <stefan.eissing@greenbytes.de>
wrote:
>>> 
>>>> Am 20.02.2017 um 15:16 schrieb Jim Jagielski <jim@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


Mime
View raw message