Re: [Discuss-gnuradio] Proper use of scoped_lock in out-of-tree module?

[Tom Rondeau]

On Wed, Jul 3, 2013 at 1:40 AM, Monahan-Mitchell, Tim
<address@hidden> wrote:
> Ø  The associated mutex is usually a (private) member variable of a class,
> and is used as a synchronization object by different class methods.  As a
> member variable, you have a choice to name it whatever you want.  If the
> mutex is the only one in the class, we usually call it d_mutex.  If there is
> more than one mutex in the class, then we give it a unique name.
>
> Ø  If you're writing your own code as a class, making the mutex a member
> variable and calling it d_mutex, and calling the local scoped lock object
> 'guard', is probably the most descriptive, but again, it's up to you.
>
> OK, that helps, thanks.
>
>
>
> One additional question – looking file_meta_source_impl.cc, it uses
> ‘d_mutex’ in all cases; in most places in the file, the object is called
> ‘guard(d_mutex)’. But in one place the object is called ‘lock(d_mutex)’… Is
> that a mistake?

Just an oversight, possibly put in a different time. It doesn't matter
because the variable guard and lock are in different scopes and exist
at different times. It's a local name, and each time we created a
scoped_lock, we could have named it something else (guard0, guard1,
guard2). No reason that they need to be the same and no reason for
them to be different.

> I got concerned when I read some about this on the net, saying that it is
> easy to forget that a local object will get destroyed when the scope that
> created it closes. Hence the need for d_mutex to get defined as a private
> class member (but it compiles fine if that step is forgotten).

Yes, exactly. The scoped_lock variable is local. It uses d_mutex to
lock the mutex during its own lifetime. When the variable goes out of
scope, d_mutex is unlocked and another call to scoped_lock can now
acquire it.

>
> Tim

Tom