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