[Asterisk-Dev] Moving towards macros..

[Kevin P. Fleming]

Kevin P. Fleming wrote:

> Brian's point (which didn't really answer your question) was very valid; 
> I have already converted app_queue to use finer-grained locking to 
> combat the very problem he referred to. I'll be interested to see if 
> these new macros can help me make it an even cleaner implementation; I 
> was just about to implement refcounts and object destruction myself, but 
> now I don't have to :-)

Well, I spoke to soon... I'm in discussions with Mark about improving 
some of the flaws/etc. I've found in astobj.h but this a biggie...

Until the current implementation is "fixed", the locking overhead is 
actually worse than it was before! For example, if your chan_sip peer 
list contains 100 entries, then:

old model:

caller locks list

caller calls find_peer, which iterates over list

caller unlocks list and uses return value for peer (locking it if needed)

Total lock/unlock pairs: 2

new model:

caller calls ASTOBJ_CONTAINER_FIND, which locks the list and iterates 
over it, locking every single list entry as it passes

caller uses return value for peer (locking it if needed)

Total lock/unlock pairs: 52 (on average)

This means a far greater potential for lock contention; in fact, if a 
thread in chan_sip is currently changing a peer entry to reflect the 
outside world and has that entry locked (as it should), it stops all 
other threads from being able to traverse the list past that peer (they 
will all block).

This is correctable, however, so stay tuned :-)