[asterisk-dev] Locking, coding guidelines addition

[Steve Murphy]

On Fri, 2008-06-27 at 13:17 -0500, Russell Bryant wrote:
> After doing some code review and responding to changes to this list,
> and then the following discussion on the #asterisk-dev channel, it has
> occurred to me that the fundamental locking rules for the boundary
> between channel drivers and the Asterisk core have not sufficiently
> been documented.  Thus, I propose the following addition to the coding
> guidelines document.
> 
> 
> I welcome any feedback.  If anything is not clear, I will do my best to 
> 


I'm sorry, but on the subject of channel and pvt locking, I have a
different thought, and I hope it's neither too late nor an unwelcome
thought. Perhaps  it's outrageous or impossible... but...

I keep asking myself, "Why do we have separate locks for the pvt and
channel structs, why not consolidate them into a single lock?"

A channel lock should be obtained before a pvt lock. So, theoretically,
the pvt lock might provide a finer locking... on a subset of the channel
data. But, since any other section of code that might want to play with
the pvt data can't/shouldn't do so until it has the channel lock first,
well, it's already covered!

Also, why this arbitrary separation of channel and pvt data? Isn't the 
whole concept of pvt data just because a subset of the channel data is
specific to a certain technology? Pvt data is really channel data, it's
just part of a conceptual union (implemented with a pointer). Pvt data
is really just channel data. 

Well, most likely I'm missing some critical factoid that demands this 
separation. But if all it is one small (but seemingly critical) factoid,
can't we work around it somehow and unify the two?

It would seem to me that if unified the pvt and channel data (at least
lockwise), it would simplify the locking situation tremendously. And 
having a channel driver just tweak pvt data wouldn't require any 
lock-order reversals, etc.

As Russell has previously said, if we astobj2-ify the channels, that
would eliminate the possibility of channels disappearing while a 
structure was being accessed. (if we are really, really careful 
about how/where/when we remove refs and destroy things)... 
And, we can define different astobj2 tables for different
kinds of find_channel needs... a complete by-name search would be
one table. We could handle name-prefix searches with a trie; channel
by exten with another hash table... and so on.

If we rwlock the channel, we could allow several competing threads to
at least access (just reading) a channel's info without blocking 
each other out.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080630/13156636/attachment.bin