[strongSwan-dev] [PATCH] log: do not acquire lock if nobody is listening
christophe.gouault at 6wind.com
Tue Apr 15 15:48:05 CEST 2014
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
> 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
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.
More information about the Dev