[strongSwan-dev] [PATCH] log: do not acquire lock if nobody is listening

[Christophe Gouault]

On 04/15/2014 10:31 AM, Christophe Gouault wrote:

> On 04/14/2014 06:31 PM, Tobias Brunner wrote:
>> It seems strange that acquiring an *uncontested* read lock (the write
>> lock is only very rarely held, in your case probably never) can produce
>> such a massive overhead.  Acquiring such a lock should be possible
>> without syscall, just some atomic compare-and-swap operation should be
>> sufficient.
>
> I was also surprised by this behavior. I didn't expect spin_locks to be
> invoked on a read lock.

I had a look at the source code for pthread_rwlock_rdlock in the glibc
nptl implementation.

The implementation of pthread_rwlock_rdlock calls lll_lock to protect
critical sections within its own pthread library data structures.
__pthread_rwlock_rdlock perform several operations under this internal
lock (check flags, increment counters...). Once done, the lock is
released with lll_unlock.

The lll_lock function may call a kernel futex under contention.

This means that, even if there are only readers:

- contention may happen due to critical sections in pthread_rwlock_rdlock
- system calls may be invoked

Read locks are in fact more costly than one usually thinks.

>> Unless, of course, your architecture does not support such atomic
>> operations, hence the library has to resort to using a regular
>> (spin-)lock.  Or if the library just is not optimized very much and
>> always does this.
>>
>> It might not be a bad idea to check if there is any potential in
>> optimizing the pthread_rwlock_rdlock implementation in the pthread
>> library you are using.
>
> I am using debian's libpthread-2.13.so for x86_64. I would reasonably
> expect that it supports optimized read locks.

Regards,
Christophe