Thanks for the thorough response. I am always impressed by the calibre
folks working on gr. I absolutely appreciate the difficulty of thread
synch. I was thinking of restricting different top levels from talking
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.
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 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
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.
Eric B. [email protected]
02/28/2008 06:39 PM
Eugene Grayver [email protected]
Re: [Discuss-gnuradio] Multiple top-level blocks
On Thu, Feb 28, 2008 at 06:12:33PM -0800, Eugene Grayver wrote:
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
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
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?
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