Re: [Discuss-gnuradio] Scheduler Help/Question

[Eric Blossom]

On Wed, Dec 31, 2008 at 05:41:16AM -0800, Earle Frank wrote:
> 
> I have a question about the scheduling of work.
> 
> In 'gr_single_threaded_scheduler.cc', I changed the pound-def ENABLE_LOGGING
> from 0 to 1.
> I did a 'make' and then a 'make install'.
> However, when I execute my flow graph, the log file is not generated.
> 
> Is this not the file of interest to investigate the work scheduling?

Which source are you working with? the trunk, or one of the tarballs?

The trunk is using the "thread-per-block" scheduler by default, so
if you're using that, enabling logging in
gr_single_threaded_scheduler.cc won't make any difference. 

For the thread-per-block scheduler, see runtime/gr_*tpb_*.{h,cc}

> I am also wondering about the condition to set 'making_progress' to true.
> Right now it looks for the number of outputs produced to be greater than 0.
> Should the condition be: ( ( num_produced > 0 ) OR ( num_consumed > 0 ) ) ?

That would probably make more sense, but I'm not sure that it matters
too much in reality.  If you try it out, let us know.

FWIW, the TPB code, gr_block_executor::run_one_iteration, handles the
situation you mention by returning the state READY_NO_OUTPUT.

> Imagine a block that has two states of operation. In a SCAN state, the block
> does not output anyway, but rather is looking at the input data for some
> kind of trigger event. In a EVENT state, the block will have a 1-to-1 input
> to output function until it goes back into the SCAN state.
> With this kind of block, 'making_progress' will false during the SCAN state.
> With the purposed condition, we would make progress.
> Is there any reasons that my thinking is wrong??
> 
> Thanks in advance,
> EF

FYI, if you're using the code in the trunk, you can select the
scheduler used at runtime by setting the GR_SCHEDULER environment
variable.  E.g., 

  $ GR_SCHEDULER=TPB ./my-gnuradio-application.py ...

or

  $ GR_SCHEDULER=STS ./my-gnuradio-application.py ...


Eric