# Regarding lock protection when setting private variables in gnuradio blocks

**URL:** <https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837>\
**Category:** GNU Radio\
**Created:** [October 15, 2014, 5:51pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837 "2014-10-15T17:51:05Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![alcina](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a587f6/32.png) [@alcina](https://www.ruby-forum.com/u/alcina)\
**Post date:** [October 15, 2014, 5:51pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/1 "2014-10-15T17:51:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 15, 2014, 6:00pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/2 "2014-10-15T18:00:36Z")

</div>

On Wed, Oct 15, 2014 at 11:49 AM, Achilleas A. \<  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> wrote:

> 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

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 15, 2014, 8:56pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/3 "2014-10-15T20:56:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 15, 2014, 10:57pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/4 "2014-10-15T22:57:40Z")

</div>

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1

Hi Achilleas,

short answer: no, it doesn’t need protection.  
long answer: as long as the only one calling forecast() is the  
thread-per-block (==default) scheduler, don’t worry, it will never  
concurrently run with work(), because it only gets called when the  
block is “idling”.

Generally, it seems that you mentally invert what you need to protect  
against concurrent access:  
You protect class members, not methods. A method might contain an  
assignment that you’d want to protect; in that case, use a scoped lock  
(like Tom illustrated).

Generally, consider it to be good style to protect every variable that  
will break your running work function when it changes mid-operation.  
For example, if you want to use a class member like d\_length\_preamble  
in your work function in a loop condition:

… work(…) {  
…  
float samples[d\_length\_preamble];  
for(float \*sample = samples; sample != samples + d\_length\_preamble;  
sample++) {  
\*sample = do\_some\_calculation();  
}  
…  
}

void set\_preamble\_length(unsigned int length){  
d\_length\_preamble = length;  
}

then ostentatiously, changing d\_length\_preamble while work is running  
might be totally disastrous. So an assignment being atomic is not the  
problem here, the question is if /access/ to the variable should be  
considered atomic. In the example above, it’s not: the loop depends on  
the value of d\_length\_preamble to not change midways through operation.

The solution to the problem above would of course be not doing  
something stupid like checking a pointer against a single address, if  
you could also just use “\<” instead, or forfeit the pointer magic and  
do everything with indices. But the point of the example was to show  
you that it’s not the setter method that needs protection – it’s the  
points where you access the member that need consideration.

So if you wanted to protect these accesses, you would insert a  
gr:🧵:scoped\_lock lock(d\_setlock);  
before the “float samples[d\_length\_preamble];” line, as well as before  
“d\_length\_preamble = length;”. As long as one of the locks is in  
scope, the other one’s creation blocks. This way, accesses can’t  
happen concurrently.

Generally, I think, since multithreading is a complex and yet  
important issue, it might be best to grab a cup of tea and your  
favourite book on object oriented software development – anything  
released after 2000 should have a chapter on multithreading,  
explaining semaphores/mutexes, conditions etc.

Greetings,  
Marcus

On 15.10.2014 20:55, Achilleas A. wrote:

> wrote:
> 
> > >
> 
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQEcBAEBAgAGBQJUPt9nAAoJEAFxB7BbsDrLSFAH/10SeeH3ZBy68MX/o0MsdAkC  
cLIF8xKVFQ9F8lNcs8BaiS/mPdDOxnJd4eHn0fmQuWpDYaoCZuOU8COzq9AZVWnz  
EhIuL7M9/LJwMX5ietxb4WolwOZbtJInGupaLuSHak9GBHmmlTK8qfMR9NTMuPGX  
blWtXEJ4xc2pkrFoo7nZS3GkohIj/gf9AbY96MI2YXP7knE9rHy+zUm+zl+JhccK  
z6OG0psuPdGplI+POKzolV2lytI8gx3cldl4dA+wzEuvc4zPTvoCxnlhP7dilY73  
78aGh1Jv9n5hoajWin3AGdaXw1tSCLdIXamYMQgBg4iBYRRHraN73vbzzdDC7n8=  
=nO4u  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 16, 2014, 4:00pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/5 "2014-10-16T16:00:24Z")

</div>

On Wed, Oct 15, 2014 at 2:55 PM, Achilleas A.  
\<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> 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  
([Chapter&nbsp;4.&nbsp;Boost.Atomic](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

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 16, 2014, 5:33pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/6 "2014-10-16T17:33:16Z")

</div>

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1

Hi Marcus,

On 16.10.2014 16:54, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

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

No; assume the following scenario:  
block (instance) “estimator”, in its work function, thinks it’s cool  
to update block (instance) “equalizer”'s internal state by calling  
equalizer\_sptr-\>set\_taps(…). In the meantime, the equalizer’s work  
is running.

so, now equalizer\_sptr-\>set\_taps runs in estimator’s thread, while it  
modifies stuff that gets accessed from equalizer’s thread.

Now, the solution to that is either using mutexes (which will, if not  
done on a very high granularity, lead to blocks running effectively  
single-threaded, because blocks block each other)  
OR employing some notifier/listener scheme and let the blocks’  
executors work through the updates after their work run in their own  
thread. That way, you end up with a variant of the “new” style async  
message passing framework, where messages cannot interfere with  
running work functions, and message handling is guaranteed to be  
reentrant-safe.

Greetings,  
Marcus

> > > Is “forecast()”" need to be protected in such a case as well?  
> > > So no about the forecast issue. Unless your forecast method uses  
> > > float, double, etc behave fine in multithreaded environments. I’m
> > 
> > variable that is used in the work function, do we need to protect
> 
> Links: ------ [1]  
> [Chapter&nbsp;4.&nbsp;Boost.Atomic](http://www.boost.org/doc/libs/1_53_0/doc/html/atomic.html) [2]  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)
> 
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Discuss-gnuradio  
> mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQEcBAEBAgAGBQJUP+TrAAoJEAFxB7BbsDrLqkUH/juNua+b3rID0Nt9/U75xX4K  
uMsQNFK39OO3s3eACM/zFQQ6pL1g8sOVaHh76lwkfYP+bXS2sF+hnDmfLN9Zw5kG  
VCbDWYuohMWBN0Ti0yMimocEDD9AO1IkaofC/p4/4HemlS6dNiJuviRWhbIki/6A  
V9daWfs92nybtf610wy2k+QUqT+IpmKR+YdacE0wwHsmiBMwDU8+4lk76H/Wrclt  
SG15zuvRHOcaBVfwY+Bkdnqub4e9uqc9JM8+Qo1+ayutkzQb5SeEWou1MbJ2QGdK  
6SpsRGUSaffb/bMk06RZRJwazWZmboTRnIKC++FsIHmpvr72d/DGetOvlDfMe1I=  
=fvJN  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 16, 2014, 5:33pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/7 "2014-10-16T17:33:52Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 16, 2014, 4:56pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/8 "2014-10-16T16:56:58Z")

</div>

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 R. wrote:

> 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:🧵:scoped\_lock lock(d\_setlock);
> 
> Tom

* * *

Discuss-gnuradio mailing list  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [2]

Links:

---

<div class="post-metadata">

**Author:** ![Achilleas\_A](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/74df32/32.png) [@Achilleas\_A](https://www.ruby-forum.com/u/Achilleas_A)\
**Post date:** [October 16, 2014, 7:01pm UTC](https://www.ruby-forum.com/t/regarding-lock-protection-when-setting-private-variables-in-gnuradio-blocks/234837/9 "2014-10-16T19:01:22Z")

</div>

Yeah, so, a little cerebral flatulence on my part.

I think the problems come in with variables that can “change shape”  
during a setting operation, which could lead

to horrific badness if the “shape change” happens while the work  
function is using the variable. Imagine a

private buffer whose size and, potentially, base-address, can change  
during the work function.

The scalars are “safer”, but not completely “safe”, in that they could  
have semantics with bad consequences if

they change during work function processing. Those bad consequences can  
be either rather benign–for example

a gain changing during processing of samples–just leads to a glitch,  
or much-worse, core-dumping territory.