Archived
14
0
Fork 0

Merged revisions 81832 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81832 | russell | 2007-09-06 17:28:57 -0500 (Thu, 06 Sep 2007) | 16 lines

(closes issue #9724, closes issue #10374)
Reported by: kenw
Patches:
      9724.txt uploaded by russell (license 2)
Tested by: kenw, russell

Resolve a deadlock that occurs when doing a SIP transfer to parking.  

I come across this type of deadlock fairly often it seems.  It is very important
to mind the boundary between the channel driver and the core in respect to the
channel lock and the channel-pvt lock.  Channel drivers lock to lock the
pvt and then the channel once it calls into the core, while the core will do
it in the opposite order.  The way this is avoided is by having channel drivers
either release their pvt lock while calling into the core, or such as in this
case, unlocking the pvt just long enough to acquire the channel lock.

........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@81839 f38db490-d61c-443f-a65b-d21fe96a405b
This commit is contained in:
russell 2007-09-06 22:30:15 +00:00
parent ab1df9e704
commit d281d6fcdf

View file

@ -14008,8 +14008,17 @@ static int sip_park(struct ast_channel *chan1, struct ast_channel *chan2, struct
transferer->readformat = chan2->readformat;
transferer->writeformat = chan2->writeformat;
/* Prepare for taking over the channel */
/* Prepare for taking over the channel. Go ahead and grab this channel
* lock here to avoid a deadlock with callbacks into the channel driver
* that hold the channel lock and want the pvt lock. */
while (ast_channel_trylock(chan2)) {
struct sip_pvt *pvt = chan2->tech_pvt;
ast_mutex_unlock(&pvt->lock);
usleep(1);
ast_mutex_lock(&pvt->lock);
}
ast_channel_masquerade(transferer, chan2);
ast_channel_unlock(chan2);
/* Setup the extensions and such */
ast_copy_string(transferer->context, chan2->context, sizeof(transferer->context));