[asterisk-commits] russell: trunk r38201 - in /trunk: ./ channels/chan_zap.c

[asterisk-commits at lists.digium.com]

Author: russell
Date: Tue Jul 25 14:51:31 2006
New Revision: 38201

URL: http://svn.digium.com/view/asterisk?rev=38201&view=rev
Log:
This exact deadlock situation that I observed can't happen in trunk due to the
recent hold changes so that MOH is not started on the bridged channel directly.
However, the change is still not a bad idea.

Merged revisions 38200 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r38200 | russell | 2006-07-25 15:43:38 -0400 (Tue, 25 Jul 2006) | 6 lines

This resolves a deadlock that a tech support customer was getting frequently
when his users would answer call waiting. If another thread is currently
holding the zt_pvt lock for the first channel, unlock both channels and let
asterisk retry the native bridge, just like what is done for the second channel
directly below these changes.

........

Modified:
    trunk/   (props changed)
    trunk/channels/chan_zap.c

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.2-merged' - no diff available.

Modified: trunk/channels/chan_zap.c
URL: http://svn.digium.com/view/asterisk/trunk/channels/chan_zap.c?rev=38201&r1=38200&r2=38201&view=diff
==============================================================================
--- trunk/channels/chan_zap.c (original)
+++ trunk/channels/chan_zap.c Tue Jul 25 14:51:31 2006
@@ -3117,7 +3117,13 @@
 	oc0 = p0->owner;
 	oc1 = p1->owner;
 
-	ast_mutex_lock(&p0->lock);
+	if (ast_mutex_trylock(&p0->lock)) {
+		/* Don't block, due to potential for deadlock */
+		ast_mutex_unlock(&c0->lock);
+		ast_mutex_unlock(&c1->lock);
+		ast_log(LOG_NOTICE, "Avoiding deadlock...\n");
+		return AST_BRIDGE_RETRY;
+	}
 	if (ast_mutex_trylock(&p1->lock)) {
 		/* Don't block, due to potential for deadlock */
 		ast_mutex_unlock(&p0->lock);