Thanks, got it. I was using a
custom source that did not block, just returned 0.
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Eric Blossom <address@hidden>
02/29/2008 12:03 PM
Eugene Grayver <address@hidden>
Re: [Discuss-gnuradio] Multiple top-level
On Fri, Feb 29, 2008 at 09:44:41AM -0800, Eugene Grayver
> Thanks for the thorough response. I am always impressed by the
> folks working on gr. I absolutely appreciate the difficulty
> synch. I was thinking of restricting different top levels from
> each other (i.e. they are _truly_ independent). However, I can
> this restriction may be violated making the system unstable.
> I'd like a bit more discussion of the second part of my question.
> a simple receiver running at a low input rate (e.g. large decimation).
> far I can tell, the scheduler sits in an infinite loop, checking if
> 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
> 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
> Eugene Grayver <address@hidden>
> 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?
> > like some insight into the philosophy behind it. E.g. why
> > 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
> every tried to robustly mix threads, signals, blocking system calls
> and reliable shutdown, you may have some appreciation of the level
> 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
> > the desired behavior. Consider two threads with different
> > requirements. One needs 90% the other 10% of the CPU. The
> > thread should relinquish control if it has nothing to do. However,
> > 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
> for another. It'll be blocked waiting on something. You
> 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.