[asterisk-dev] [Code Review] 2826: Debug threads: avoid double-initialization of lock tracking

[rmudgett]

> On Sept. 21, 2013, 4:11 a.m., rmudgett wrote:
> > /branches/1.8/main/lock.c, line 146
> > <https://reviewboard.asterisk.org/r/2826/diff/3/?file=45654#file45654line146>
> >
> >     Lock tracking initialization must be deferred until the mutex or rwlock is actually used.  Otherwise, it is no different than putting the tracking memory into the ast_mutex_t struct.
> >     
> >     Lock tracking used to be part of the ast_mutex_t until it was discovered that chan_iax was using 100M bytes just being loaded.  chan_iax has a 32k element lock array that it initializes when it loads.
> 
> David Lee wrote:
>     That's the whole problem, though. There's no way to synchronize
>     initialization on first use. Multiple threads trying to simultaneously
>     acquire a lock with uninitialized lock tracking could result in double
>     initialization.
>     
>     Maybe it would be better if DEBUG_THREADS dramatically reduced the
>     size of that array in chan_iax.

Reducing the size of that array is not an option.  The size of that array is the range of call numbers chan_iax2 will accept for calls.


- rmudgett


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2826/#review9754
-----------------------------------------------------------


On Sept. 5, 2013, 6:24 p.m., David Lee wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2826/
> -----------------------------------------------------------
> 
> (Updated Sept. 5, 2013, 6:24 p.m.)
> 
> 
> Review request for Asterisk Developers and Matt Jordan.
> 
> 
> Bugs: ASTERISK-19463
>     https://issues.asterisk.org/jira/browse/ASTERISK-19463
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch corrects a consistency issue with debug threads that I
> noticed while fixing ASTERISK-22455.
> 
> The initialization of a mutex's lock tracking structure was not
> protected in a critical section. This is fine for any mutex that is
> explicitly initialized, but a static mutex may have its lock tracking
> double-initialized if multiple threads attempt the first lock
> simultaneously.
> 
> This patch creates a global mutex to properly serialize the
> initialization of the lock tracking structure for a mutex. It also
> changes lock.c to properly handle allocation failures of the lock
> tracking structure.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/lock.h 398421 
>   /branches/1.8/main/lock.c 398421 
> 
> Diff: https://reviewboard.asterisk.org/r/2826/diff/
> 
> 
> Testing
> -------
> 
> I propose we setup Bamboo to run the TestSuite with DEBUG_THREADS
> enabled on this branch nightly for a few weeks.
> 
> 
> Thanks,
> 
> David Lee
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130923/f64004f7/attachment-0001.htm>