[asterisk-dev] [Code Review] 3405: Add ast_spinlock capability
reviewboard at asterisk.org
Fri Apr 18 18:09:18 CDT 2014
This is an automatically generated e-mail. To reply, visit:
(Updated April 18, 2014, 5:09 p.m.)
Review request for Asterisk Developers, Corey Farrell, Joshua Colp, and rmudgett.
Updated with a few changes suggested by rmudgett.
Now ready for prime time...
This patch adds support for spinlocks in Asterisk.
There are cases in Asterisk where it might be desirable to lock a short critical code section but not incur the context switch and yield penalty of a mutex or rwlock. The primary spinlock implementations execute exclusively in userspace and therefore don't incur those penalties. Spinlocks are NOT meant to be a general replacement for mutexes. They should be used only for protecting short blocks of critical code such as simple compares and assignments. Operations that may block, hold a lock, or cause the thread to give up it's timeslice should NEVER be attempted in a spinlock.
The first use case for spinlocks is in astobj2 - internal_ao2_ref. Currently the manipulation of the reference counter is done with an ast_atomic_fetchadd_int which works fine. When weak reference containers are introduced however, there's an additional comparison and assignment that'll need to be done while the lock is held. A mutex would be way too expensive here, hence the spinlock. Given that lock contention in this situation would be infrequent, the overhead of the spinlock is only a few more machine instructions than the current ast_atomic_fetchadd_int call.
7 implementations were tested on various i366, x86_64, ARM and Sparc platforms running Linux, FreeBSD, OSX and Solaris. The test suite and results can be found here... https://github.com/gtjoseph/spintest
Tested various spinlock implementations.
+ GCC Atomics gcc_atomics
+ x86 assembly gas_x86
+ ARM assembly gas_arm
+ Sparc assembly gas_sparc
+ OSX Atomics osx_atomics
+ pthreads spinlock pthread_spinlock
+ pthreads mutex pthread_mutex
+ pthreads adaptive mutex pthread_mutex_adaptive_np
Not all implementations were available on all platforms. For instance, the gas_x86 implementation won't be available on an arm or sparc platform.
Each implementation was tested with the same locking scenario which is a short block of compares and assignments representing the most anticipated Asterisk use cases. The test case was run in a tight loop of 25,000,000 iterations executed in parallel by 1..5 simultaneous threads.
The test suite was run on the following platforms:
For each platform tested, the real, user and system times were captured in csv form and the final real and system times graphed.
+ The GCC Atomics implementation was available on all platforms and generally had the best performance.
+ The native assembly implementations generally performed on par with the GCC Atomics implementation.
+ The pthread_spinlock implementation was not available on Darwin but performed well on the other platforms.
+ The OSX Atomics implementation performed well on Darwin.
+ The pthread_mutex_adaptive implementation was not available on all platforms and it's performance was noticeably worse on the supported platforms.
+ The pthread_mutex implementation was available on all platforms but clearly showed the effects of context switching (high sys time) as lock contention grew.
+ GCC Atomics should be the first implementation choice.
+ The native assembly implementations should be the second choices.
+ The pthread_spinlock implementation should be the third choice on non-Darwin platforms.
+ OSX Atomics should be the third choice on Darwin.
+ The pthread_mutex_adaptive implementation should be eliminated.
+ The pthread_mutex implementation should be the implementation of last resort.
+ If none of the implementations are available, a compilation #error will be raised.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-dev