Re: [Discuss-gnuradio] Multiple top-level blocks

[Eric Blossom]

On Fri, Feb 29, 2008 at 09:44:41AM -0800, Eugene Grayver wrote:
> Thanks for the thorough response.  I am always impressed by the calibre of 
> folks working on gr.  I absolutely appreciate the difficulty of thread 
> synch.  I was thinking of restricting different top levels from talking to 
> each other (i.e. they are _truly_ independent).  However, I can see how 
> this restriction may be violated making the system unstable.
> 
> I'd like a bit more discussion of the second part of my question. Consider 
> a simple receiver running at a low input rate (e.g. large decimation).  As 
> far I can tell, the scheduler sits in an infinite loop, checking if the 
> source has data.

The sources (or sinks) will block if there's nothing available (e.g., USRP).
It does not spin.  It does relinquish if there's nothing to do.

> If it does not, the loop goes back to the beginning. 
> There's no blocking.  Perhaps the scheduler should relinquish the rest of 
> the time slice if it find no block to 'work' in a given pass?  I don't 
> know of a platform independent way to do that.

If the code behaved as you think, we would always be consuming all cpu
cycles available.  We don't.

> ________________________
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> ________________________
> 
> 
> 
> Eric Blossom <address@hidden> 
> 02/28/2008 06:39 PM
> 
> To
> Eugene Grayver <address@hidden>
> cc
> address@hidden
> Subject
> Re: [Discuss-gnuradio] Multiple top-level blocks
> 
> On Thu, Feb 28, 2008 at 06:12:33PM -0800, Eugene Grayver wrote:
> > Hello,
> > 
> > Is there any documentation of the new C++ only gnuradio framework?  I'd 
> > like some insight into the philosophy behind it.  E.g. why can there 
> only 
> > be one top level block?  Consider an example:
> 
> The one top block constraint is an implementation detail (restriction)
> that will be removed as part of the thread-per-block work.  If you've
> every tried to robustly mix threads, signals, blocking system calls
> and reliable shutdown, you may have some appreciation of the level of
> effort required to make this work correctly.
> 
> > The gr_top_block appears to separate the flow graph into independent 
> > subgraphs and runs each one in its own thread.  I wonder if this is 
> always 
> > the desired behavior.  Consider two threads with different computational 
> 
> > requirements.  One needs 90% the other 10% of the CPU.  The low rate 
> > thread should relinquish control if it has nothing to do.  However, that 
> 
> > will not happen.  Instead, the scheduler will sit there and use up the 
> > entire time to check if the graph has unblocked.  Any ideas?
> > 
> > Thanks.
> 
> I think you misunderstand the details of what's going on.  The
> low-rate thread will relinquish control.  No thread is spinning waiting
> for another.  It'll be blocked waiting on something.  You are correct
> in your assessment that we're not currently making good use of
> multicore resources.  That will be fixed in as part of the
> thread-per-block work.
> 
> Eric