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

[Johnathan Corgan]

On 07/02/2013 10:40 PM, Monahan-Mitchell, Tim wrote:

> 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).

Just to be clear, there are two variables here. The 'd_mutex' is a class
variable, usually private (but doesn't have to be.) It serves as a
common synchronization object to allow multiple threads to coordinate
use of some resource, over the lifetime of a class instance, by being
locked and unlocked as needed by class methods.

The other variable, 'guard' or 'lock' or 'l', is the thing doing the
locking in individual methods that must synchronize access.  As a scoped
lock, it is designed to lock the mutex given as a constructor parameter
when it is created, and unlock that mutex when it goes out of scope and
is destroyed.  The common pattern, then, is to make it a local variable
in a method, so that it goes in and out of scope (and acquires and
releases the mutex) automatically, while the code within that scope can
assume it is holding the lock exclusively to any other thread.

Since this is a variable and not some language keyword, you can name it
whatever you like.  'guard' is common, but it doesn't have to be the
same each time it is used.

What specifically do you mean when you say 'compiles fine if that step
is forgotten' ?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

signature.asc
Description: OpenPGP digital signature