[asterisk-dev] [Code Review]: Astobj2 locking enhancement

[rmudgett]

> On Feb. 24, 2012, 5:20 p.m., Kevin Fleming wrote:
> > /trunk/include/asterisk/astobj2.h, line 388
> > <https://reviewboard.asterisk.org/r/1554/diff/1/?file=21542#file21542line388>
> >
> >     Please do a global search/replace of 'Ao2' with 'ao2'. :-)

done


> On Feb. 24, 2012, 5:20 p.m., Kevin Fleming wrote:
> > /trunk/include/asterisk/astobj2.h, line 592
> > <https://reviewboard.asterisk.org/r/1554/diff/1/?file=21542#file21542line592>
> >
> >     blob

done


> On Feb. 24, 2012, 5:20 p.m., Kevin Fleming wrote:
> > /trunk/include/asterisk/astobj2.h, line 607
> > <https://reviewboard.asterisk.org/r/1554/diff/1/?file=21542#file21542line607>
> >
> >     blob

done


> On Feb. 24, 2012, 5:20 p.m., Kevin Fleming wrote:
> > /trunk/include/asterisk/astobj2.h, lines 736-737
> > <https://reviewboard.asterisk.org/r/1554/diff/1/?file=21542#file21542line736>
> >
> >     I'm not sure I follow this; if a rdlock is promoted to a wrlock, it can't be demoted to a rdlock without releasing it first. Is that the intention here?

Yes, that is the intention so the locking level will remain the same when the ao2 call returns.

Promotion to wrlock from rdlock already releases the lock to re-obtain it as a wrlock.


> On Feb. 24, 2012, 5:20 p.m., Kevin Fleming wrote:
> > /trunk/main/astobj2.c, line 353
> > <https://reviewboard.asterisk.org/r/1554/diff/1/?file=21544#file21544line353>
> >
> >     'the possible RWLOCK' seems like an odd way to describe this. "Attempt to adjust an object's lock to the requested level", with a comment in the body about how the adjustment may differ based on whether the lock is a mutex or an rwlock would probably be more understandable.

Adjusted the \brief and \details sections.


- rmudgett


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


On Oct. 31, 2011, 3:01 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1554/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2011, 3:01 p.m.)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> Add the ability to specify what kind of locking an ao2 object has when it is allocated.
> The locking could be one of: MUTEX, RWLOCK, or none.
> 
> New API:
> 
> ao2_t_alloc_options()
> ao2_alloc_options()
> ao2_t_container_alloc_options()
> ao2_container_alloc_options()
> 
> ao2_rdlock()
> ao2_wrlock()
> ao2_tryrdlock()
> ao2_trywrlock()
> 
> The OBJ_NOLOCK and AO2_ITERATOR_DONTLOCK flags have a slight meaning 
> change.  They no longer mean that the object is protected by an external 
> mechanism.  They mean the lock associated with the object has already been 
> manually obtained by one of the ao2_lock calls.  This change is necessary 
> for RWLOCK support since they are not reentrant.  Also an operation on an 
> ao2 container may require promoting a read lock to a write lock by 
> releasing the already held read lock to re-acquire as a write lock.  
> 
> 
> The changes to format.c and format_cap.c are taking advantange of the new 
> ao2 locking options to simplify the use of the format capabilities 
> containers.  
> 
> 
> Diffs
> -----
> 
>   /trunk/include/asterisk/lock.h 342867 
>   /trunk/main/astobj2.c 342867 
>   /trunk/main/format.c 342867 
>   /trunk/main/format_cap.c 342867 
>   /trunk/include/asterisk/astobj2.h 342867 
> 
> Diff: https://reviewboard.asterisk.org/r/1554/diff
> 
> 
> Testing
> -------
> 
> Ran the ao2 unit tests.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120225/10dac257/attachment.htm>