[asterisk-dev] Proper use of locking.

[Derek Smithies]

Kevin,

> this is a very complex area to work in
It surely is a complex area to work in. threaded code (vs non threaded 
code) is what separates the programmers from the children.

Michael had noted three significant areas of concern
a)use of thread safe lists 
b)copying data soas to minimise the length of time a lock is held
c)reentrant mutexes

In the email below, it seems that you are arguing there are read write 
locks. But, is this on an entire list, or is this on elements in the list.
 Thus, is it going to be possible for multiple threads to read from 
 the same list at the same time ?

It does appear that you guys are moving to reentant mutexes - it is a slow 
process to change to a more reasonable mutexing system.

And of the need to copy data (which is reported for logging (say)) and 
then freeing the mutex in the minimum of time - is there any plan of work 
in this direction ?



Thanks,

Derek.

 On Thu, 19 Jul 2007, Kevin P. Fleming wrote:

> Michael Cargile wrote:

> No doubt; this is a very complex area to work in, and we have to be
> extremely careful when we make these changes to fully understand their
> impact and potential negatives. In SVN trunk some of these places have
> already been changed to rwlocks, which will make an enormous difference
> since the execution profile for many of these code paths is 90% reads
> and 10% writes (or even more skewed).
> 
> > The only way I see to facilitate this is for those people who are
> > committing patches to reject ones that do silly things like those that I
> > wrote about in my previous email, have a janitorial project to scour the
> > code looking for these issues and fix them, and to write a good locking
> > practices section into the coding guidelines. I am more than willing to
> > help with all of these (except the checking patches for commit as I do
> > not have commit writes). We will probably be hiring someone else to do
> > so as well here in the not too distant future. We are planning to use
> > Asterisk for very a large call volume application shortly and having
> > Asterisk stable and performing optimally will save us far more than the
> > cost of a full time developer.
> 
> As anyone who has posted a complex patch to the issue tracker will tell
> you, we already very stringently check contributions (and our own code)
> for things like this, and in many cases this causes us to reject patches
> and require the contributor to go back and re-work their code. While I
> won't in any way say that we are perfect at it, I can't believe that
> there have been patches accepted in the recent past that have such
> egregious locking problems as you are describing; if there are, I would
> appreciate pointers to them.
> 
> 

-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek at indranet.co.nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/