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
_______________________________________________
Dev mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/dev
