Re: [Discuss-gnuradio] GNURadio retrictions

[Mostafa Alizadeh]

Hi Marcus,

On Mon, Nov 24, 2014 at 1:33 AM, Marcus Müller <address@hidden> wrote:

Hi Mostafa,

On 11/23/2014 10:39 PM, Mostafa Alizadeh wrote:
> 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.
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.

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

 

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

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

 

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

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