# Multi thread fft execution

**URL:** <https://www.ruby-forum.com/t/multi-thread-fft-execution/232743>\
**Category:** GNU Radio\
**Created:** [October 25, 2014, 12:04pm UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743 "2014-10-25T12:04:35Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [October 25, 2014, 12:04pm UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/1 "2014-10-25T12:04:35Z")

</div>

Hi all,  
I have the following c++ code which gets fft by sliding on sample by  
sample  
fo the input.

```
/*

 * The private constructor

 */

sliding_fft_impl::sliding_fft_impl(uint fft_size)

  : gr::sync_block("sliding_fft",

          gr::io_signature::make(1, 1, sizeof(gr_complex)),

          gr::io_signature::make(1, 1, fft_size * 

```

sizeof(gr\_complex))),

```
    d_fft_size(fft_size)

{

    d_fft = new fft::fft_complex (d_fft_size, 1, 2);

    set_history(fft_size);

}

sliding_fft_impl::~sliding_fft_impl()

{

    delete d_fft;

}

int

sliding_fft_impl::work(int noutput_items,

    gr_vector_const_void_star &input_items,

    gr_vector_void_star &output_items)

{

    const gr_complex *in = (const gr_complex *) input_items[0];

    gr_complex *out = (gr_complex *) output_items[0];

    memcpy(d_fft->get_inbuf(), in, d_fft_size * sizeof(gr_complex));

    d_fft->execute();

    memcpy(out, d_fft->get_outbuf(), d_fft_size * 

```

sizeof(gr\_complex));

```
    //delete d_fft;

    return 1;

}

```

If I run the fft execution on 2 threads, or more, is there any “race”  
problem between these 2 threads and the work one? Inj another words,  
is it possible that this work being called before finishing the fft  
execution?

If it is so, there will be a race problem because “work” wants to  
write on d\_fft-\>get\_inbuf() while fft execution wants to read from it!

please help me with this code. I don’t know why at the runtime, the  
data I give at the output aren’t desired after a while!!

Best,

Mostafa

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [October 25, 2014, 2:28pm UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/2 "2014-10-25T14:28:32Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [October 25, 2014, 4:40pm UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/3 "2014-10-25T16:40:01Z")

</div>

On 10/25/2014 08:26 AM, Marcus M. wrote:

> 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.

Sliding FFTs are used to provide spectral estimates with higher temporal  
resolution, while sacrificing (to some extent) the overall quality of  
the estimate.

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [October 26, 2014, 6:15am UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/4 "2014-10-26T06:15:09Z")

</div>

Hello Marcus,  
I checked my sliding fft works fine and the bug was somewhere else 🙂

In fact I want to detect a known sequence within data non-coherently.  
After  
detection I want to neglect this ‘work’ process.  
How would you prefer to stop this work process after detection?  
(Something  
like putting this thread to sleep! )

Best,  
Mostafa

On Sat, Oct 25, 2014 at 3:56 PM, Marcus M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> spawn thread 1 & spawn thread 2  
> interference while the fft threads run, because at that time, the work  
> Your code looks correct. I know I tell you this in almost every discussion  
> Greetings,  
> /\*
> 
> ```
> }
> 
> gr_complex *out = (gr_complex *) output_items[0];
> 
> ```
> 
> Mostafa  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

–

* * *

Department of Electrical Engineering  
Aboureyhan Building  
MMWCL LAB  
Amirkabir University Of Technology  
Tehran  
IRAN  
Tel: +98 (919) 158-7730  
LAB: [http://ele.aut.ac.ir/~mmwcl/?page\_id=411](http://ele.aut.ac.ir/~mmwcl/?page_id=411)  
Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/)

* * *

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [October 26, 2014, 7:30am UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/5 "2014-10-26T07:30:42Z")

</div>

That would be a case for flow graph reconfiguration, most probably 🙂

---

<div class="post-metadata">

**Author:** ![mostafa\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/5e9695/32.png) [@mostafa\_a](https://www.ruby-forum.com/u/mostafa_a)\
**Post date:** [October 26, 2014, 6:17am UTC](https://www.ruby-forum.com/t/multi-thread-fft-execution/232743/6 "2014-10-26T06:17:32Z")

</div>

Sliding fft is fundamentally different from spectral estimation in  
practice. Because in practice we never do sliding on sample by sample to  
get estimate of spectrum.

The using purpose of sliding fft here is something else.

Best,

On Sat, Oct 25, 2014 at 6:08 PM, Marcus D. Leech [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Sliding FFTs are used to provide spectral estimates with higher temporal

–

* * *

Department of Electrical Engineering  
Aboureyhan Building  
MMWCL LAB  
Amirkabir University Of Technology  
Tehran  
IRAN  
Tel: +98 (919) 158-7730  
LAB: [http://ele.aut.ac.ir/~mmwcl/?page\_id=411](http://ele.aut.ac.ir/~mmwcl/?page_id=411)  
Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/)

* * *