Multiple top-level blocks

GNU Radio
1

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:

I have a transmitter and a receiver. The two are completely
independent.
Why can’t each one be a gr_top_block? I may want to stop one but not
the
other.

The tx and rx may have been designed by different people. Why do I need
another top level to combine the two?

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.

2

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

3

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. 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.

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

Eric B. [email protected]
02/28/2008 06:39 PM

To
Eugene Grayver [email protected]
cc
[email protected]
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

4

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 B. [email protected]
02/29/2008 12:03 PM

To
Eugene Grayver [email protected]
cc
[email protected]
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.

Is there any documentation of the new C++ only gnuradio framework? I’d
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

5

On Fri, Feb 29, 2008 at 01:09:33PM -0800, Eugene Grayver wrote:

Thanks, got it. I was using a custom source that did not block, just
returned 0.

FWIW, sources or sinks that return 0 are generally a bad idea.

Eric

6

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.