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

[Kevin Fleming]

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



/trunk/include/asterisk/astobj2.h
<https://reviewboard.asterisk.org/r/1554/#comment10292>

    Please do a global search/replace of 'Ao2' with 'ao2'. :-)



/trunk/include/asterisk/astobj2.h
<https://reviewboard.asterisk.org/r/1554/#comment10293>

    blob



/trunk/include/asterisk/astobj2.h
<https://reviewboard.asterisk.org/r/1554/#comment10294>

    blob



/trunk/include/asterisk/astobj2.h
<https://reviewboard.asterisk.org/r/1554/#comment10295>

    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?



/trunk/include/asterisk/astobj2.h
<https://reviewboard.asterisk.org/r/1554/#comment10296>

    Same comment as above.



/trunk/main/astobj2.c
<https://reviewboard.asterisk.org/r/1554/#comment10298>

    '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.


- Kevin


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/20120224/7ca3f5f4/attachment.htm>