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 <[EMAIL PROTECTED]> > 02/28/2008 06:39 PM > > To > Eugene Grayver <[EMAIL PROTECTED]> > cc > discuss-gnuradio@gnu.org > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio