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