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

[Monahan-Mitchell, Tim]

>> 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' ?

In my GR 3.6.4.2-based OOT module, I placed a line like this where I wanted 
exclusivity from other entry points (copied from looking at examples in the 
gnuradio tree):

gruel::scoped_lock l(d_setlock);

... and did nothing else (no #include, no declaration of d_setlock anywhere). I 
used gr_modtool to generate the skeleton files. It compiled and ran without 
complaints (on VMware x86 and ARM target). As to whether it actually did what 
it was supposed to do, I don't know. I have since seen occurrences of 
"#include<gruel/attributes.h>" in the template header files, but I was dumb and 
happy at this point, so no worries. (You should have deduced by now that I 
don't use C++ much...)

While stepping up to GR 3.7, one of the things to change was that include line, 
which made me investigate more, and I read this article: 
http://jek-thoughts.blogspot.com/2010/06/pitfalls-of-scoped-lock.html . That 
caused me to start this thread.

So I have higher confidence now that I'm using the scope lock tool correctly, 
thanks again.