Re: [Discuss-gnuradio] GNURadio retrictions

[Martin Braun]

On 11/25/2014 07:37 AM, Mostafa Alizadeh 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::thread::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