|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Threaded GRC blocks |
Date: | Fri, 16 Jan 2015 19:02:34 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
:)I have no doubt I'm doing GNU radio wrong,I might have put that a little harsh; sorry. You're not doing it wrong, you just weren't aware of a few core concepts of the GNU Radio scheduler: but I'm a bit confused as to how to implement this otherwise, as I don't want my processing completed on every block coming in and I don't want samples to stop while I'm processingAnd exactly that's the kind of worries GNU Radio strives to take away from you. All blocks in your flow graph can run in parallel. So while your block is still working, the upstream block is already processing what is going to be the input of your block's next iteration, while your downstream block is busy processing what your block produced the last time. Also, GNU Radio uses input and output buffers, which are identical to your upstream block's output and your downstream blocks' input buffers, respectively, and makes sure you know how many space there is in these buffers (or how much samples there are for you to process). This all is done transparently in separate threads, so you don't have to worry about it. I hope that illustrates why I think that spawning your own thread is not necessary; it's already being done for you, and in a manner that allows you not to care about the correct transportation of data, notifying threads, ensuring data flow and proper multiprocessor scaling -- this all happens behind the curtains. To the user, each block only has to care about processing its input as fast as possible to produce output; the scheduler will coordinate everything else. In fact, GNU Radio even encourages you to think about how you can further break down your algorithm, to as well avoid re-inventing the wheel, and to use optimized algorithms. Maybe you do an FFT inside? Well, then use the existing GNU Radio FFT. Are you multiplying to sample streams? Do that with a GNU radio multiply block, and you'll profit from SIMD-optimized routines. Also, when breaking down an algorithm into existing and to-be-written blocks, you increase the level of parallelity, which generally is a good thing, because buffering necessary to avoid congestion when a step takes especially long will then be automatically distributed between a lot of blocks. Greetings, Marcus On 01/16/2015 06:45 PM, Jon West wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |