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