# Fftw3 thread safety?

**URL:** <https://www.ruby-forum.com/t/fftw3-thread-safety/231530>\
**Category:** GNU Radio\
**Created:** [August 13, 2014, 5:37pm UTC](https://www.ruby-forum.com/t/fftw3-thread-safety/231530 "2014-08-13T17:37:11Z")\
**Posts on this page:** 3\
**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:** [August 13, 2014, 5:37pm UTC](https://www.ruby-forum.com/t/fftw3-thread-safety/231530/1 "2014-08-13T17:37:11Z")

</div>

I am facing an issue with one of my decoding blocks in which I call  
“manually” FFTW3 (ie _not_ going through the gnuradio-fftw3  
implementation since I have not (yet) understood how it operates). If I  
call a processing chain with a single appearance of my processing  
block, all goes fine. If I add a second decoding block (for example for  
decoding a second channel), gnuradio crashes after a couple of seconds.  
I tracked the issue to the fftw3 thread safety and apparently some  
global variable shared by all task planners. Can someone point me to  
the way gnuradio solves this thread safety issue (which must be solved  
since I can use as many FFT display blocks I want) ? The semaphore  
solution is not really satisfactory since I’d like not to ask my block  
to wait for all other data processing to be completed before I can  
complete its own task.

Thanks, JM

---

<div class="post-metadata">

**Author:** ![jmfriedt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@jmfriedt](https://www.ruby-forum.com/u/jmfriedt)\
**Post date:** [August 13, 2014, 6:29pm UTC](https://www.ruby-forum.com/t/fftw3-thread-safety/231530/2 "2014-08-13T18:29:37Z")

</div>

On Wed, Aug 13, 2014 at 8:35 AM, jmfriedt  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I tracked the issue to the fftw3 thread safety and apparently some  
> global variable shared by all task planners. Can someone point me to  
> the way gnuradio solves this thread safety issue (which must be solved  
> since I can use as many FFT display blocks I want) ? The semaphore  
> solution is not really satisfactory since I’d like not to ask my block  
> to wait for all other data processing to be completed before I can  
> complete its own task.

I have just a general thought on fftw. The plan - during generation -  
is the only part of fftw that must be explicitly protected or run from  
a single thread. If you’re calling execute on the same plan from  
multiple threads, or different plans that share the same memory, then  
that memory needs protection to prevent garbled samples. Otherwise, no  
thread protection should be necessary for the execution call.

-TT

---

<div class="post-metadata">

**Author:** ![jmfriedt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@jmfriedt](https://www.ruby-forum.com/u/jmfriedt)\
**Post date:** [August 14, 2014, 12:53pm UTC](https://www.ruby-forum.com/t/fftw3-thread-safety/231530/3 "2014-08-14T12:53:49Z")

</div>

Hi,

> Can someone point me to  
> the way gnuradio solves this thread safety issue (which must be solved  
> since I can use as many FFT display blocks I want) ?

See planner::mutex() in gr-fft/lib/fft.cc

> The semaphore  
> solution is not really satisfactory since I’d like not to ask my block  
> to wait for all other data processing to be completed before I can  
> complete its own task.

The execution (fftw\_execute and variants) is safe and can be executed  
by several threads in //, even on the same plan object.

Cheers,

Sylvain