|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] multi thread fft execution |
Date: | Sat, 25 Oct 2014 14:26:38 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
Hi Mostafa,
>is there any "race" problem between these 2 threads and the work one? I think you might be confused what the FFT multithreading means here; I hope I can illustrate this. Let's set the FFT multithreading level to two threads: sliding_fft_impl::work() | enter "fft->execute" spawn thread 1 & spawn thread 2 | | calculate calculate | | +--------v-------+ join threads | return from "fft->execute" continue ::work The work thread waits for fft->execute to return; there can be no interference while the fft threads run, because at that time, the work thread isn't "active". >Inj another words, is it possible that this work being called before finishing the fft execution? no, a single block's work() cannot get called before the previous run of work() has finished. That wouldn't make any sense -- how would the second work now how many input samples it has, if the first one hadn't already consumed? Your code looks correct. I know I tell you this in almost every discussion on here, but: Please, tell us what "undesired" means. That would greatly reduce the guesswork for the rest of the mailing list. Also, sliding FFTs do look like a computational heavy load. What is the application for that? I ask because getting an fft_length FFT for every item increases item/sample rate without giving you (information-theoretically speaking) any advantage over doing one FFT ever fft_length samples. Greetings, Marcus On 10/25/2014 12:03 PM, Mostafa Alizadeh wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |