This bugzilla service is closed. All entries have been migrated to
Bug 1483 - FFTW FFT implementation is not thread safe.
Summary: FFTW FFT implementation is not thread safe.
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Unsupported modules (show other bugs)
Version: 3.2
Hardware: x86 - 64-bit Linux
: Normal Crash
Assignee: Nobody
Depends on:
Reported: 2017-11-09 13:14 UTC by Youssef Bagoulla
Modified: 2019-12-04 17:16 UTC (History)
2 users (show)


Description Youssef Bagoulla 2017-11-09 13:14:21 UTC
The short version of the bug is that the unsupported FFTW FFT implementation is not thread safe. It could easily be made thread safe if a lock was added around the plan call however I was not sure what locking mechanism to use in a patch since Eigen is cross platform. I also did not see any lock examples in a quick grep of the codebase. 

The reason it is not thread safe is due to the thread safety of the underlying FFTW library. Two threads cannot call plan at the same time. (Documented here: 

Users who use FFTW > 3.3.5 (myself not included in this) may use the fftw_make_planner_thread_safe option but it would be better if eigen guarded against the issue.

Example application below, compiled on CentOS7 with FFTW 3.3.3 and the following command: 
g++ testFFT.cpp -std=c++11 -I/usr/include/eigen3/ -pthread -DEIGEN_FFTW_DEFAULT -lfftw3 -lfftw3f

#include <unsupported/Eigen/FFT>
#include <Eigen/Core>
#include <thread>
#include <complex>
#include <atomic>
#include <chrono>

using namespace Eigen;
using namespace std;

atomic<bool> _run;

void worker() {
  while (_run) {
    FFT<float> fft;
    vector<float> timeV(1024);
    vector<complex<float> > freqV(1024);
    fft.fwd(freqV, timeV);

int main() {
  vector<thread> threads;
  _run = true;
  for (size_t i = 0; i < 1024; ++i)


  _run = false;
  for (auto &thread : threads)

  return 0;
Comment 1 Gael Guennebaud 2017-11-10 13:29:47 UTC
There are two options:

1) document that Eigen::FFT + EIGEN_FFTW_DEFAULT + fftw<3.3.5 is not thread safe, and they have to use their own  favorite lock.

2) add a lock if FFTW<3.3.5 and if
  a) c++11 enabled -> use C++11 lock
  b) c++03 only + openmp -> use openmp lock
  c) if FFTW<3.3.5 + c++03 only + no openmp, give up and fallback to option 1) ;)
Comment 2 Gael Guennebaud 2017-11-10 13:30:21 UTC
and of course, if FFTW>3.3.5 let's use fftw_make_planner_thread_safe
Comment 3 Nobody 2019-12-04 17:16:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.