Forgot to CC: the list: 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. 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). > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio