GNU Radio Scheduler

From some GNU Radio documentation:

while enabled and nalive > 0 do
  for i = 1, 2, ...,#blocks do
    if sufficient room in output port bu!ers for block i
      and data at input ports of block i then
        invoke general work() on block i ;
    end if
  end for
end while

• The single-threaded scheduler <gr_scheduler_sts> is essentially deprecated
• GNU Radio scheduler operates on flow-graphs composed of processing blocks
• A thread is created for each block, they are managed together in a thread_group list

Thread Creation

std::auto_ptr thrd(new boost::thread(threadfunc));

From discuss-gnuradio

On Jan 28, 2011, at 2:23 PM, Ben Hilburn wrote:
> As I understand it, there is code in the GNURadio scheduler stuff that
> manages block scheduling, to some degree.
> 
> I'm aware of the kernel's role in switching between the threads
> themselves, but I was under the impression that block scheduling, was
> at least in some part, influenced by GNU Radio.
> 
> If this is incorrect though, someone please correct me!

Yes, this is true, Ben. The OS handles the basics of thread execution, but the
TPB scheduler does handle "when" a block's "general_work" method is actually
called. See gnuradio-core/src/lib/runtime, files "gr_tpb_thread_body.cc"
(which for the most part is a simple loop calling the block executor and
neighbor blocks when things change) and "gr_block_executor.cc" (which is where
the meat of what you're looking for it, I believe). For the latter, you can
set ENABLE_LOGGING to 1, which should give you an idea of what the "decision
process" is.

I think the general idea goes roughly like this: When data in a given buffer
changes (whether through generated or consumed items), each block that is
associated with that buffer checks to see if there is "enough" input data and
output buffer space for a "reasonable sized" computation. If not, then go back
and wait for buffers to change; if so, then do the computation (call
"general_work"). You'll need to look through the code to determine what
"enough" and "reasonable sized" mean -- looking at the debug log might help as
well.

It's been a long time since I've thought about these algorithms, so hopefully
the above is reasonably correct. And, I hope this helps! - MLD

So, gr_block_executer is the one actually doing the work - it calls each block's general_work() function.

Enable Logging: scheduling problems are identified and solved much easier if logging is enabled. In gr_block_executer.cc define ENABLE_LOGGING = 1. This creates log files in the current working directory which include information about the number of items passed to general_work() and the value returned.