Hi Marcus, On Mon, Nov 24, 2014 at 1:33 AM, Marcus Müller <[email protected]> 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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
