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

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On April 11, 2013, 10:16 p.m., Shaun Ruffell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2441/
> -----------------------------------------------------------
> 
> (Updated April 11, 2013, 10:16 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 385382 
> 
> 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/20130419/61663939/attachment.htm>