On Wed, Jul 3, 2013 at 1:40 AM, Monahan-Mitchell, Tim <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
