Hi,<br><br>Call me a troublemaker, or maybe Captain Obvious&#39; cousin, but locking/deadlock issues have been behind 90% or more of the issues I&#39;ve got involved in, bug reported, or fixed, over the last few years. &nbsp;&nbsp;So Russell: I think _most_ Asterisk issues are to do with this problem, and we _do_ have an even bigger problem. &nbsp;(Maybe that&#39;s because I do lots of IAX2, and iax2 has really suffered from these issues since the worker thread stuff was put in).<br>
<br>Unfortunately its an architectural problem. &nbsp;<br><br>I think the discussion reveals that the magic trylock while loop looks neato but doesn&#39;t really solve the problem. &nbsp;Tzafrir and Luigi pointed out some flaws.<br>
<br>Mutexes and all this stuff are safe _provided_ that a locking order is respected. &nbsp;If locking order isn&#39;t respected, you&#39;re always on the bleeding edge where some innocuous change tips something else over the edge and, voila, a deadlock.<br>
<br>This is all harder in Asterisk because locks are help sometimes over large areas of code - making it hard to see all the possible code paths. &nbsp;<br><br>So it seems to me that the nettle must be grasped, a strict locking order defined, and the code needs to be gradually adjusted to match that definition. &nbsp;I don&#39;t see any other way.<br>
<br>In your example of an incoming call for a channel - well, the channel must lock the ast_channel before the pvt structure. &nbsp;(or, remove the pvt lock as Steve suggested).<br><br>It would also help to clean up the coding style so that the &quot;scope&quot; of a held lock is more clearly visible in the code structure. &nbsp;This helps comprehension.<br>
<br>By the way - a locking order is a tricky thing. &nbsp;It needs to be defined *within* a class of object too. &nbsp;Like: if a thread needs to lock more than one channel - there must be a defined order between the channels, too.<br>
<br>I note also that introducing astobj2 into chan_iax2 also had an initial bad effect on stability, showing that there are dragons down that road, too. &nbsp;I guess they are in the requirement to reference count.<br><br>Regards,<br>
Steve<br>