[asterisk-dev] Proper use of locking.

[Michael Cargile]

On Thu, 2007-07-19 at 18:42 -0500, Tilghman Lesher wrote:
> It was originally coded with non-recursive mutexes, and we had to jump
> through a number of hoops to get around the non-reentrancy of the
> mutexes.  However, as Kevin has stated repeatedly in this thread, that
> change happened YEARS ago.  All mutexes in Asterisk are currently
> recursive.

I do not care about what was in the past. If the mutexes are in fact
recursive now that is great. It is possible that the bug I fixed a year
and a half ago was actually in an add on or something like that and I am
just confused. If Asterisk is using recursive mutexes that if
fantastic :-D

This does not change the fact that there are a number of places within
the Asterisk code where mutexes are being using sub-optimally. I am not
trying to point fingers at anyone or say that anything has been
mismanaged. All I want to see done is some effort put towards fixing
these issues. I am more than willing to spend my free time fixing them
and the company I am working for is planning on hiring someone full time
to help improve the performance of Asterisk who can help with this as
well. I would just like to see the 1.6 version of Asterisk being the
most stable and best performing version of Asterisk to date so I can get
rid of 1.2 and all of the back ports I am using.

I would also like to see a section added to the coding guidelines
spelling out the proper use of mutexes in Asterisk so that new people
joining in on the development do not fall into the same pitfalls. I am
more than willing to write said section. There are already a number of
sections in the coding guidelines that I feel should be self explanatory
such as not recomputing values over and over again and never use an
uninitialized variable. Adding something along the lines of avoiding
doing I/O (either to a file, network adapter, or a terminal) while
within as mutex where ever possible is just as important and would
probably have a far more significant impact on performance.

Michael Cargile
Explido Software USA Inc.
www.explido.us