[Asterisk-Dev] ASTOBJ update

[Kevin P. Fleming]

Matthew Boehm wrote:

> #define ASTOBJ_WRLOCK(object) ast_mutex_lock(&(object)->_lock)
> 
> Why is using this macro better than just calling the function? What kind of
> performance gain is seen? Where is it seen?

In addition to what I already responded with, there's another benefit: 
opacity. It's better to hide the implementation details from the ASTOBJ 
users so that people don't try to intentionally do things in a different 
(possibly incompatible and/or broken) way. Obviously everyone can see 
the source and figure out what is going on, but if a future version of 
ASTOBJ should use a very different locking model then we don't have to 
worry about changing callers, especially since that change might be much 
more difficult than a search-and-replace.

For example, there are "lockless" list reading algorithms out there 
(IBM's RCU is one). If we should decide to integrate one of those at 
some point, then doing a "search-and-replace" on ast_mutex_lock for 
everyone using ASTOBJ variables would be a very time consuming and 
error-prone task. Redefining ASTOBJ_RDLOCK to a no-op takes about 5 
seconds :-)

This discussion has brought up something I hadn't considered yesterday 
though... we need another set of macros for locking, to be used when the 
object is being locked in its "list container" role, as opposed to its 
"object" role. That way we can split them apart if needed in the future. 
Watch for a new patch :-)