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 <[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
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
