>> 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
