diff options
author | George Joseph <george.joseph@fairview5.com> | 2014-04-23 20:13:30 +0000 |
---|---|---|
committer | George Joseph <george.joseph@fairview5.com> | 2014-04-23 20:13:30 +0000 |
commit | 64045f0b57f8524e133373c1d75a36db3fa022cc (patch) | |
tree | c3bfcd3ad6bc3809025ec7e417e2d2efe2e331f2 /static-http/mantest.html | |
parent | e6c4b9752116ecc71220c03db1493a05c38b051a (diff) |
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.
ASTERISK-23553 #close
Review: https://reviewboard.asterisk.org/r/3405/
........
Merged revisions 412976 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'static-http/mantest.html')
0 files changed, 0 insertions, 0 deletions