[asterisk-dev] [Code Review] 2441: res_timing_pthread: Reduce probability of deadlocking on timer.

Matt Jordan reviewboard at asterisk.org
Thu Apr 11 17:02:40 CDT 2013



> On April 11, 2013, 8:36 p.m., Mark Michelson wrote:
> >

There's actually a rather subtle bug with this patch that I'm still working through. I'll post a follow-up when I've got it nailed down.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2441/#review8239
-----------------------------------------------------------


On April 10, 2013, 8:11 p.m., Shaun Ruffell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2441/
> -----------------------------------------------------------
> 
> (Updated April 10, 2013, 8:11 p.m.)
> 
> 
> Review request for Asterisk Developers and Matt Jordan.
> 
> 
> Bugs: ASTERISK-21389
>     https://issues.asterisk.org/jira/browse/ASTERISK-21389
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> From the patch attached on ASTERISK-21389:
> 
> res_timing_pthread: Reduce probability of deadlocking on timer.
> 
> There were several reports of deadlock when using
> res_timing_pthread. Backtraces indicated that one thread was blocked
> waiting for the write to the pipe to complete and this thread held
> the container lock for the timers.  Therefore any thread that wanted
> to create a new timer or read an existing timer would block waiting
> for either the timer lock or the container lock and deadlock ensued.
> 
> This patch changes the way the pipe is used to eliminate this source
> of deadlocks:
> 
> 1) The pipe is placed in non-blocking mode so that it would never
> block even if the following changes someone fail...
> 
> 2) Instead of writing bytes into the pipe for each "tick" that's
> fired the pipe now has two states--signaled and unsignaled. If
> signaled, the pipe is hot and any pollers of the read side
> filedescriptor will be woken up. If unsigned the pipe is idle. This
> eliminates even the chance of filling up the pipe and reduces the
> potential overhead of calling unnecessary writes.
> 
> 3) Since we're tracking the signaled / unsignaled state, we can
> eliminate the exta poll system call for every firing because we know
> that there is data to be read.
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_timing_pthread.c 385267 
> 
> Diff: https://reviewboard.asterisk.org/r/2441/diff/
> 
> 
> Testing
> -------
> 
> ran timing test on the console and also put several channels in a confbridge.
> 
> 
> Thanks,
> 
> Shaun Ruffell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130411/2ce246ad/attachment-0001.htm>


More information about the asterisk-dev mailing list