discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Multiple top-level blocks


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Multiple top-level blocks
Date: Thu, 28 Feb 2008 18:39:51 -0800
User-agent: Mutt/1.5.17 (2007-11-01)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]