1c462653e7
The bigzaplock was used to prevent changes to all the channels during masterspan processing while conference parameters were changing. The master span processing also took a global lock out on the chan_lock to prevent new channels from being registered or unregistered during processing. Instead of grabbing both those locks, just changing the semantics of chan_lock to those of bigzaplock seems to fit the bill and removes another lock from the driver (and saves ~10 ns on a 2.40 GHz Xeon in prcocess_masterspan) chan_lock is a candidate for conversion to RCU but usage in conferencing (bigzaplock type usage) needs to be audited carefully before conversion. Signed-off-by: Shaun Ruffell <sruffell@digium.com> Acked-by: Kinsey Moore <kmoore@digium.com> Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com> Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com> Review: https://reviewboard.asterisk.org/r/940/ git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9414 a0bf4364-ded3-4de4-8d8a-66a801d63aff |
||
|---|---|---|
| .. | ||
| dahdi | ||