[asterisk-dev] [Code Review] 2881: Performance: Taskprocessor optimization; switch Stasis to use taskprocessors

[Mark Michelson]

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



/branches/12/main/sem.c
<https://reviewboard.asterisk.org/r/2881/#comment19022>

    To mirror typical semaphore behavior, you should return an error and set errno to EINVAL if value exceeds SEM_VALUE_MAX;
    
    Also, since semaphore values should never dip below 0, you should probably assert that value >= 0.



/branches/12/main/sem.c
<https://reviewboard.asterisk.org/r/2881/#comment19023>

    If it's available, you should probably use SEM_VALUE_MAX here instead of INT_MAX.


- Mark Michelson


On Sept. 25, 2013, 10:13 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2881/
> -----------------------------------------------------------
> 
> (Updated Sept. 25, 2013, 10:13 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch optimizes taskprocessor to use a semaphore for signaling,
> which the OS can do a better job at managing contention and waiting
> that we can with a mutex and condition.
> 
> The taskprocessor execution was also slightly optimized to reduce the
> number of locks taken.
> 
> The only observable difference in the taskprocessor implementation is
> that when the final reference to the taskprocessor goes away, it will
> execute all tasks to completion instead of discarding the unexecuted
> tasks.
> 
> For systems where unnamed semaphores are not supported, a really
> simple semaphore implementation is provided. (Which gives identical
> performance as the original taskprocessor implementation).
> 
> The way we ended up implementing Stasis caused the threadpool to be a
> burden instead of a boost to performance. This was switched to just
> use taskprocessors directly for subscriptions.
> 
> 
> Diffs
> -----
> 
>   /branches/12/main/taskprocessor.c 399869 
>   /branches/12/main/stasis_config.c 399869 
>   /branches/12/main/sem.c PRE-CREATION 
>   /branches/12/main/stasis.c 399869 
>   /branches/12/include/asterisk/taskprocessor.h 399869 
>   /branches/12/include/asterisk/stasis.h 399869 
>   /branches/12/include/asterisk/sem.h PRE-CREATION 
>   /branches/12/include/asterisk/autoconfig.h.in 399869 
>   /branches/12/configure UNKNOWN 
>   /branches/12/configure.ac 399869 
>   /branches/12/configs/stasis.conf.sample 399869 
> 
> Diff: https://reviewboard.asterisk.org/r/2881/diff/
> 
> 
> Testing
> -------
> 
> Unit tests pass.
> 
> Same performance test as from https://reviewboard.asterisk.org/r/2873/
> 
> 
> Thanks,
> 
> David Lee
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130926/8b24b7d3/attachment-0002.html>