Re: [Discuss-gnuradio] Regarding lock protection when setting private variables in gnuradio blocks

[Tom Rondeau]

On Wed, Oct 15, 2014 at 2:55 PM, Achilleas Anastasopoulos <address@hidden> wrote:

Is "forecast()"" need to be protected in such a case as well?

just searching on the web i realized that no operation can be assumed atomic, so
I guess every single set_ method (even if it assigns a float/int/short/char) needs to be protected...is this an overkill?

Achilleas

Achilleas,

So no about the forecast issue. Unless your forecast method uses non-atomic variables that can be set using a function setter. Marcus' response more completely outlines why forecast is thread safe between itself and the work function.

On the atomic issue, yes, you're technically correct that there really is no such thing as an atomic data type. C++11 more officially defines concepts of atomic data types, and Boost introduced it's atomic type (I believe) in 1.53 (http://www.boost.org/doc/libs/1_53_0/doc/html/atomic.html). However, for all intents and purposes, 

things like int, char, float, double, etc behave fine in multithreaded environments. I'm trying to remember where I went over this in some depth at one point, but the result is that while they are not technically atomic, they behave correctly -- and I wish I could explain more thoroughly why right now.

We will be moving our Boost version requirements to >= 1.53 in our 3.8 release, which means we can start using their atomic type concept then.

Tom

 

On Wed, Oct 15, 2014 at 11:59 AM, Tom Rondeau <address@hidden> wrote:

On Wed, Oct 15, 2014 at 11:49 AM, Achilleas Anastasopoulos <address@hidden> wrote:

My question arose from a comment that Jonathan made on one of the pull requests

in gnuradio (#293).

If we have a set function in a gr block that sets some private variable that is

used in the work function, do we need to protect it to make the whole operation thread safe?

Is this a standard practice in gnuradio blocks?

eg, why is this not used in "add_const_vXX_impl.h.t" ?

thanks
Achilleas

If it's not atomic, then yes, you really should protect it. All blocks have a mutex called d_setlock you can easily use for this:

      gr::thread::scoped_lock lock(d_setlock);

Tom