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.
Tel: 310.336.1274
________________________
Eric Blossom <address@hidden>
02/29/2008 12:03 PM
To
Eugene Grayver <address@hidden>
cc
address@hidden
Subject
Re: [Discuss-gnuradio] Multiple top-level
blocks
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