Fftw3 thread safety?

GNU Radio
1

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

2

On Wed, Aug 13, 2014 at 8:35 AM, jmfriedt
[email protected] 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

3

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