# GNURadio retrictions

**URL:** <https://www.ruby-forum.com/t/gnuradio-retrictions/233198>\
**Category:** GNU Radio\
**Created:** [November 23, 2014, 10:41pm UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198 "2014-11-23T22:41:01Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [November 23, 2014, 10:41pm UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/1 "2014-11-23T22:41:01Z")

</div>

Hello GNURadioers!

I’ve been working with GNURadio since about one year ago. I just figured  
out the following limitation of GNURadio’s framework that I want to  
diacuss  
them to clarify whether I’m wrong or not:

1- For general blocks with multiple output ports, there is a problem  
with  
the amount of producing items when the general work routine just gives  
you  
the “maximum” available number of output items for all output ports, and  
also set\_output\_multiple or other functions like set\_alignment dealing  
with  
all output ports rather than individual ones. So if one wants to produce  
items on the output ports with large different numbers, such as 100  
items  
on one port and 2000 items on the other one, the scheduler will fail to  
manage this high “diverse” ports.

2- The scheduler jumps through different blocks before finishing the  
work  
routine’s job which causes some problems. For example, consider the  
below  
code which is placed somewhere in the work (general\_work ):

“”"""""""""""""""  
memcpy (out, temp, n\_out\_produced \* sizeof(gr\_complex);

produce(0, n\_out\_produced);

add\_item\_tag(0, nitems\_written(0), … , … );  
“”"""""""""""""""

So if we change the order of the code like this:

“”"""""""""""""""  
memcpy (out, temp, n\_out\_produced \* sizeof(gr\_complex);

add\_item\_tag(0, nitems\_written(0), … , … );

produce(0, n\_out\_produced);  
“”"""""""""""""""

In the second case there is no problem with tagging process, although in  
the first case the scheduler may jump out of this block right after  
calling  
produce function, so the position of the tagging which is "  
nitems\_written(0)" will change to the new value. Suppose in the next  
call  
to the first code, after calling produce function, the add\_item\_tag is  
called and the item is tagged on “nitems\_written(0)” position which is  
the  
same as the previous call. So these two consecutive tags are placed on  
the  
same position in the stream. Why is this happening? This is just because  
before finishing the job of this work routine, scheduler jumps somewhere  
else.

Please help me find the rational reason!

Thanks in advance,  
Alizadeh

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 24, 2014, 1:42pm UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/2 "2014-11-24T13:42:23Z")

</div>

> Please help me find the rational reason!

Because calling “produce” means, “I’m done, go ahead and take those  
sample”.  
Don’t call it until you are reall done …

GR is a multi-threaded applications, each work() function is executed  
in different threads and as soon as you call produce(), other threads  
are signalled that the samples are ready.

Cheers,

Sylvain

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 24, 2014, 2:30pm UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/3 "2014-11-24T14:30:54Z")

</div>

Forgot to CC: the list:

Hi Mostafa,

On 11/23/2014 10:39 PM, Mostafa A. wrote:

> on one port and 2000 items on the other one, the scheduler will fail to  
> manage this high “diverse” ports.  
> Ok, I think this needs some explanation. What does “fail to manage”  
> imply exactly?  
> Generally, I think if you’re having something like a block that produces  
> 2000 samples on one, and 100 on another, but does not have a fixed rate  
> between in- and output, this sounds you like, from a logical point of  
> view as much as by performance considerations, be better of using  
> messages.

But I think if you illustrate more closely, it’s likely we can figure  
out where the problem lies.

> 2- The scheduler jumps through different blocks before finishing the work  
> routine’s job which causes some problems.  
> No, it doesn’t. At least the GNU Radio scheduler won’t interrupt a work  
> function  
> Ok, so here’s the problem I have with your phrasing: you use  
> “scheduler”, and I _assume_ you mean the GNU Radio scheduler.

It’s the thread-per-block scheduler, which executes multiple blocks  
/simultaneously/.

Underneath, of course, lies a runtime environment (boost threads), which  
uses underlying threading libraries (on unixoids usually pthreads),  
which use the underlying operating system’s multithreading routines  
(aka. the OS’s scheduler) , which will execute blocks interleaved  
(depending on system architecture, number of CPUs etc).

> So if we change the order of the code like this:
> 
> “”“”“”“”“”“”“”“”"  
> memcpy (out, temp, n\_out\_produced \* sizeof(gr\_complex);
> 
> add\_item\_tag(0, nitems\_written(0), … , … );
> 
> produce(0, n\_out\_produced);  
> “”“”“”“”“”“”“”“”"  
> Obviously, calling produce() increments the value that nitems\_written()  
> should return! (nitems\_written is “number of produced samples”)  
> So these are two very different programs, semantically.
> 
> In the second case there is no problem with tagging process, although in  
> the first case the scheduler may jump out of this block right after calling  
> produce function,  
> No, he doesn’t 😉 you’ve just written buggy code.

Greetings,  
Marcus

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 25, 2014, 7:43am UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/4 "2014-11-25T07:43:42Z")

</div>

On Mon, Nov 24, 2014 at 4:11 PM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Cheers,
> 
> Sylvain

Hi Sylvain,

I infer from what you said that what I see is true and logical! In  
another  
word, the nitems\_written can be updated permanently in the middle of the  
work’s routine. OK

But I still think that this is not logical to update the number of items  
written before returning from work call.

Thank you,  
Mostafa

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 25, 2014, 9:21am UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/5 "2014-11-25T09:21:57Z")

</div>

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

As Sylvain said, produce() actually means “hey, I’m finished with  
producing these items, so do what you want in another block (ie. in  
another thread”, so obviously, the things like nitems\_written must  
reflect this.

On 11/25/2014 07:42 AM, Mostafa A. wrote:

> > other threads are signalled that the samples are ready.  
> > I infer from what you said that what I see is true and logical! In  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ 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

iQEcBAEBAgAGBQJUdDu+AAoJEAFxB7BbsDrL/ZoH/jhy/Mqgfe6EyU2gA1fId11o  
fi9CMUYGd0n0vbqgqHap4+qYbDeKdFNk81jp2KgOyqPC8Al/JPlVQJNX3QwFW+w3  
O4a1hMqHbGIf9ktP45kpuQH/PgH1yMJD805IueJYjxBqrU2VDXTuGr9P8dqfbfz9  
xCrbkHMDLIV0eJEiZ67d3U3ldFUj1XSYBsPRdpAs+hnsmsfmyUB6fJHGxucil1DW  
o6a0FxU4dZvAfdcjSUTkz2Kq8N9NUekPcMfBeTDDZqMctdDUtv0+Ggr8cqZ++uHd  
SqscQLEbS8XXnTrSEXb3PLij/wz2f+4AZFkPlzRDc/0R4jHiCdW/E1lpkWznwtQ=  
=N8Wx  
-----END PGP SIGNATURE-----

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 26, 2014, 12:40am UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/6 "2014-11-26T00:40:41Z")

</div>

Hi Marcus,

On Mon, Nov 24, 2014 at 1:33 AM, Marcus M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> you  
> 2000 samples on one, and 100 on another, but does not have a fixed rate  
> between in- and output, this sounds you like, from a logical point of  
> view as much as by performance considerations, be better of using messages.

That’s a good idea ( using messages instead)!

> But I think if you illustrate more closely, it’s likely we can figure  
> out where the problem lies.
> 
> > 2- The scheduler jumps through different blocks before finishing the work  
> > routine’s job which causes some problems.  
> > No, it doesn’t. At least the GNU Radio scheduler won’t interrupt a work  
> > function

I believe in what I see in GNURadio! It forsakes the work’s routine  
somewhere in amidst of it!!

> (depending on system architecture, number of CPUs etc).

OK, these information doesn’t solve the problem at least for me who  
don’t  
know anything about boost.

> > 
> 
> should return! (nitems\_written is “number of produced samples”)  
> So these are two very different programs, semantically.
> 
> > In the second case there is no problem with tagging process, although in  
> > the first case the scheduler may jump out of this block right after  
> > calling  
> > produce function,  
> > No, he doesn’t 😉 you’ve just written buggy code.

Greetings,

> Marcus

I swear that I wrote a clean code :), I see what I see.

This is also so complicated, I forgot to add, that sometime calling the  
produce() function before add\_item\_tag() increments the nitems\_written()  
and sometime doesn’t!!! why??

Best,  
Mostafa

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 26, 2014, 2:42am UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/7 "2014-11-26T02:42:39Z")

</div>

Hi Mostafa

On 11/25/2014 07:37 AM, Mostafa A. wrote:

> > No, it doesn’t. At least the GNU Radio scheduler won’t interrupt a work  
> > function
> 
> I believe in what I see in GNURadio! It forsakes the work’s routine  
> somewhere in amidst of it!!  
> This would _really_ surprise me. What does “forsake” mean here? Does the  
> computer then execute another work function, just to come back to the  
> current one later?

> > 
> 
> OK, these information doesn’t solve the problem at least for me who don’t  
> know anything about boost.  
> Well, the point here is that it’s not about knowing boost, it’s about  
> understanding multithreading on current operating systems, which is  
> quite a bit more theoretical. However, you’re describing problems that  
> neither Sylvain nor me can reproduce and I’m afraid you have some  
> misconception about how things in GR work together, and how a thread  
> works.

> I swear that I wrote a clean code :), I see what I see.  
> The code you shared did two different things, though you claimed it  
> should do the same. Sylvain and me _both_ pointed out that it _should  
> not_ do the same and the code works as designed. I swear your code does  
> what it should by definition. You just wrote the wrong code if you want  
> something else 🙂
> 
> This is also so complicated, I forgot to add, that sometime calling the  
> produce() function before add\_item\_tag() increments the nitems\_written()  
> and sometime doesn’t!!! why??  
> produce() will always instantly increase the value nitems\_written()  
> returns, because that is the only job of produce().  
> block::nitems\_written() just calls block\_detail::nitems\_written() which  
> returns its underlying buffer::nitems\_written() which is defined in  
> buffer.h as  
> uint64\_t nitems\_written() { return d\_abs\_write\_offset; }  
> The delegate chain for produce is block::produce returning  
> block\_detail::produce which calls buffer::update\_write\_pointer which is  
> defined in buffer.cc as  
> d\_abs\_write\_offset += nitems;  
> There’s no ambiguity anywhere here, no if()s, not a single point where  
> we don’t increase the return value of nitems\_written() by the amount of  
> samples you produce(). I don’t see how that “sometimes” could increase  
> and sometimes not. Pretty sure you’re not really seeing GNU Radio  
> misbehave.

Best regards,  
Marcus

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [November 26, 2014, 2:52am UTC](https://www.ruby-forum.com/t/gnuradio-retrictions/233198/8 "2014-11-26T02:52:21Z")

</div>

On 11/25/2014 07:37 AM, Mostafa A. wrote:

> ```
> No, it doesn't. At least the GNU Radio scheduler won't interrupt a work
> function
> 
> ```
> 
> I believe in what I see in GNURadio! It forsakes the work’s routine  
> somewhere in amidst of it!!

It really doesn’t. Other works() are also running, though.

> ```
> Underneath, of course, lies a runtime environment (boost threads), which
> uses underlying threading libraries (on unixoids usually pthreads),
> which use the underlying operating system's multithreading routines
> (aka. the OS's scheduler) , which will execute blocks interleaved
> (depending on system architecture, number of CPUs etc).
> 
> ```
> 
> OK, these information doesn’t solve the problem at least for me who  
> don’t know anything about boost.

Boost implements fairly standard multithreading paradigms, which you  
should make yourself acquainted with if you want to do multithreading  
stuff.

However, you don’t _need_ to do this. Our stuff is designed to work  
thread-safely. If you stick to all the rules and build blocks the way  
they should be written, you will only run into issues if there’s  
actually a bug, which it doesn’t sound like reading your emails.

> This is also so complicated, I forgot to add, that sometime calling the  
> produce() function before add\_item\_tag() increments the nitems\_written()  
> and sometime doesn’t!!! why??

It doesn’t. See here:

void  
block\_detail::produce(int which\_output, int how\_many\_items)  
{  
if(how\_many\_items \> 0) {  
d\_output[which\_output]-\>update\_write\_pointer(how\_many\_items);  
d\_produce\_or |= how\_many\_items;  
}  
}

and here:

void  
buffer::update\_write\_pointer(int nitems)  
{  
gr:🧵:scoped\_lock guard(\*mutex());  
d\_write\_index = index\_add(d\_write\_index, nitems);  
d\_abs\_write\_offset += nitems; // == nitems\_written()  
}

My guess is your debugging and inspection methods are inadequate.

M