httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: APR pools, mutexes and thread safe allocations
Date Mon, 20 Feb 2017 15:40:12 GMT
I mean, of course, "has a *mutex*"

> On Feb 20, 2017, at 10:39 AM, Jim Jagielski <jim@jaguNET.com> wrote:
> 
> Again, I am only talking about those in which the allocator
> has a pool... The allocator. Via  apr_allocator_mutex_set().
> 
>> On Feb 20, 2017, at 10:26 AM, Branko ─îibej <brane@apache.org> wrote:
>> 
>> On 20.02.2017 16:08, Jim Jagielski wrote:
>>> Again, this would ONLY happen if the underlying allocator has
>>> a mutex!
>> 
>> Sure, but you need an allocator with a mutex in order to safely create
>> pools in a multi-threaded environment. For all practical purposes this
>> means that the allocator must be thread-safe #ifdef APR_HAS_THREADS.
>> 
>> Now in certain cases you may have enough control of the structure of the
>> application that you're able to make a more fine-grained decision about
>> whether your allocator must be thread-safe or not. But libraries, such
>> as Subversion for example, do not have that luxury.
>> 
>> APR pools were designed with the assumption that separate threads will
>> always use separate pools whenever concurrent allocations are possible.
>> This assumption happens to fit pretty well with the
>> server/worker/thread-pool architecture that APR was designed to be used
>> in, and is not an inordinate burden for other architectures.
>> 
>> Your proposed change would drastically slow down existing code or force
>> it to use non-thread-safe allocators and invent and retrofit explicit
>> locking around subpool creation. Whilst the change is, strictly
>> speaking, backward compatible, I can imagine people being slightly
>> miffed off if their apps drastically slow down because they happen to be
>> linked with a new version of APR.
>> 
>> -- Brane
>> 
>> 
>>>> 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