[Asterisk-code-review] func_channel: Added new OTHER_CHANNEL function (asterisk[master])

[N A]

Attention is currently required from: Joshua Colp, Mark Murawski.
N A has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15893 )

Change subject: func_channel: Added new OTHER_CHANNEL function
......................................................................


Patch Set 7:

(1 comment)

Patchset:

PS7: 
> There isn't really a defined methodical way. […]
I did some analysis and I don't think there is a locking risk presented.
When setting a variable, the channel lock is obtained. In the case of on a different channel, A will lock B's channel while it's setting the variable.

Now, suppose deadlock were to occur by A and B doing a simultaneous OTHER_CHANNEL write into each other's channels. If A started first, it would ref channel B and then lock it inside pbx_builtin_setvar_helper. Now suppose at this time, B wanted to set a variable on A's channel. This isn't problematic, because A never locks itself during execution, only the other channel (B). B is perfectly fine, therefore, to go ahead and lock any other channel, such as A or B. Doing so will not inhibit the first write in any way, so in no time at all, A will finish writing B and release B's lock.

Now suppose, hypothetically, that A were to lock itself as well as lock B during an OTHER_CHANNEL write. This would prevent B from writing to A because pbx_builtin_setvar_helper would block on getting A's channel lock. However, A is free to go ahead and finish its business and then release B's lock, and then release its own lock, so by the time B acquires A's lock, its own lock is also guaranteed to be free. (This isn't the current code model, the first case is, but this is just a hypothetical exercise).

Not the most rigorous proof, but I think this reasoning shows to confirm the current behavior is safe?



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15893
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: I7492645ae4307553d0f586d78e13a4f586231fdf
Gerrit-Change-Number: 15893
Gerrit-PatchSet: 7
Gerrit-Owner: N A <mail at interlinked.x10host.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Kevin Harwell <default.enum at gmail.com>
Gerrit-Reviewer: Mark Murawski <markm at intellasoft.net>
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-CC: Joshua Colp <jcolp at sangoma.com>
Gerrit-Attention: Joshua Colp <jcolp at sangoma.com>
Gerrit-Attention: Mark Murawski <markm at intellasoft.net>
Gerrit-Comment-Date: Sat, 06 Aug 2022 20:14:39 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Joshua Colp <jcolp at sangoma.com>
Comment-In-Reply-To: N A <mail at interlinked.x10host.com>
Comment-In-Reply-To: Mark Murawski <markm at intellasoft.net>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220806/0c78104d/attachment.html>