[asterisk-dev] session channel locks

Dan Cropp dan at amtelco.com
Wed Dec 9 11:06:51 CST 2020


Thank you Joshua.

From: asterisk-dev <asterisk-dev-bounces at lists.digium.com> On Behalf Of Joshua C. Colp
Sent: Wednesday, December 9, 2020 10:27 AM
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Subject: Re: [asterisk-dev] session channel locks

On Wed, Dec 9, 2020 at 12:02 PM Dan Cropp <dan at amtelco.com<mailto:dan at amtelco.com>> wrote:
We are working on a patch for the REFER support and have a question on whether a lock is needed or not.

In chan_pjsip.c function xfer_client_on_evsub_state, code is processing the REFER-NOTIFY subscription.

It gets an ast_sip_session reference, then it acquires a ast_channel reference.
Should we make the code bump the lock count for the session’s channel while we use it?  Unlocking when done using it?

Is it safe to assume the channel will not be deleted while this routine is running?
Obviously, the safest approach is to increment/decrement the reference count while using, but is that the necessary/preferred approach?

The PJSIP implementation in Asterisk doesn't heavily use locks. Instead it approaches things from a serializer perspective - that is ensuring that things related to a dialog/session can't be done in multiple threads at the same time. To that end the xfer_client_on_evsub_state function should allocate a structure with the appropriate information and queue it up using ast_sip_push_task. You can find this being done in the chan_pjsip_transfer function. This will give you a guarantee that session won't go away, the channel pointer won't go away, and that other threads aren't doing things at the same time.

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com<http://www.sangoma.com> and www.asterisk.org<http://www.asterisk.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201209/531d72e6/attachment-0001.html>


More information about the asterisk-dev mailing list