[asterisk-dev] [Code Review] Bridging API for Conference Bridge purposes

[Vadim Lebedev]

Le 16 févr. 09 à 04:08, Russell Bryant a écrit :

>
>
>> On 2009-02-01 04:12:00, vadim wrote:
>>> /trunk/main/bridging.c, lines 1023-1028
>>> <http://reviewboard.digium.com/r/93/diff/2/?file=2260#file2260line1023 
>>> >
>>>
>>>    I beleive that to avoid deadlocks one need to unlock objects in  
>>> the inverse order of locking
>>
>> wrote:
>>    Done.
>
> Just for the sake of discussion, the order that you unlock objects  
> doesn't actually matter.  I suppose it's probably good practice to  
> unlock in the reverse order that you locked, but reversing it can  
> not cause a deadlock.
>
>

Thread 1:    Lock A    Lock  B ,     Unlock  
A,                                 Lock A,  Unlock A,  Unlock B
Thread 2:                                                            
Lock A,   Lock B
                                                                             = 
=== Deadlock =======



Vadim

P.S.   If i remember correctly the partial ordering of resources is a  
valid deadlock prevention techinque


> - Russell
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/93/#review348
> -----------------------------------------------------------
>
>
> On 2009-02-11 14:11:30, Joshua Colp wrote:
>>
>> -----------------------------------------------------------
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviewboard.digium.com/r/93/
>> -----------------------------------------------------------
>>
>> (Updated 2009-02-11 14:11:30)
>>
>>
>> Review request for Asterisk Developers and Russell Bryant.
>>
>>
>> Summary
>> -------
>>
>> This patch implements the new bridging API and brings with it a  
>> module for conference bridges. It does *not* replace existing  
>> internal bridging or features yet and will not cause any  
>> regressions when put in. It will essentially be introduced as a  
>> first test phase to work out any unforeseen critical issues. The  
>> bridging core itself is fully implemented besides the following:  
>> jitterbuffer support, native bridging, and interval hooks (hooks  
>> that are time based versus action based). If you would like an  
>> explanation of what the bridging API is made up of and how it works  
>> that can be found in the bridging.h header file.
>>
>>
>> Diffs
>> -----
>>
>>  /trunk/Makefile 174884
>>  /trunk/apps/app_confbridge.c PRE-CREATION
>>  /trunk/bridges/Makefile PRE-CREATION
>>  /trunk/bridges/bridge_builtin_features.c PRE-CREATION
>>  /trunk/bridges/bridge_multiplexed.c PRE-CREATION
>>  /trunk/bridges/bridge_simple.c PRE-CREATION
>>  /trunk/bridges/bridge_softmix.c PRE-CREATION
>>  /trunk/channels/chan_bridge.c PRE-CREATION
>>  /trunk/include/asterisk/bridging.h PRE-CREATION
>>  /trunk/include/asterisk/bridging_features.h PRE-CREATION
>>  /trunk/include/asterisk/bridging_technology.h PRE-CREATION
>>  /trunk/include/asterisk/channel.h 174884
>>  /trunk/main/Makefile 174884
>>  /trunk/main/bridging.c PRE-CREATION
>>
>> Diff: http://reviewboard.digium.com/r/93/diff
>>
>>
>> Testing
>> -------
>>
>> Conference bridge testing using app_confbridge with features.  
>> Joining two channels with simple frame exchange and joining three  
>> channels to move it to a true conference bridge. IVR capability of  
>> app_confbridge was also tested.
>>
>>
>> Thanks,
>>
>> Joshua
>>
>>
>