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 <anas...@umich.edu> > 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 [1]). 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 <t...@trondeau.com> wrote: > > On Wed, Oct 15, 2014 at 11:49 AM, Achilleas Anastasopoulos > <anas...@umich.edu> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2] Links: ------ [1] http://www.boost.org/doc/libs/1_53_0/doc/html/atomic.html [2] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
