[asterisk-dev] Channel locking mechanism in Asterisk

[Tilghman Lesher]

On Wednesday 03 November 2010 05:29:36 chaitra.bhat at lakecommunications.com 
wrote:
> I do not think we will be moving to ver 1.8.0 version of Asterisk since
> the Asterisk 1.4.22 code has been customised to suit our platform. Also,
> this huge a change might not be welcomed this late into our project. But
> since we are looking for some performance improvement in Asterisk, we
> might consider the hash table look-up for the channels.
> 
> At the same time, moving to reference counted objects for Asterisk
> channels might be a bigger risk compared to the hashing of the Asterisk
> channels. Could the hash table concept be ported independent of the
> reference-counted objects for Asterisk channels?

No, the reference counting is integral to the implementation of the hash
container.  In 1.4, the only method we have for ensuring that a channel
reference remains viable is to lock the channel itself.  The constraints
for atomically verifying that the channel is viable mean that a singular
lock must be held while the central container is checked.  So while you
might gain a slight advantage by using a hash lookup, you still would need
to lock the single container, just as in the 1.4 code.  Your single point
of contention is not ameliorated by just using a hash container.  The
refcount ensures that the channel is only deallocated when the last
reference is freed, which means you do not need to depend upon the
central container to verify whether an unlocked channel is still viable.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org