[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Regarding lock protection when setting private va

From: mleech
Subject: Re: [Discuss-gnuradio] Regarding lock protection when setting private variables in gnuradio blocks
Date: Thu, 16 Oct 2014 10:54:36 -0400
User-agent: Roundcube Webmail/1.0.2

Is it not the case that a given instance of a block is only ever executed by a single thread, so instance variables

  are completely safe to modify in-flight?


There are exceptions, of course, like in FFTW, only a single thread can be "planning" at a time, due to the

  way FFTW does its thing.





On 2014-10-16 09:58, Tom Rondeau wrote:

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?

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.
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" ?

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

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]