fftw3: Thread safety
5.4 Thread safety
=================
Users writing multi-threaded programs (including OpenMP) must concern
themselves with the "thread safety" of the libraries they use--that is,
whether it is safe to call routines in parallel from multiple threads.
FFTW can be used in such an environment, but some care must be taken
because the planner routines share data (e.g. wisdom and trigonometric
tables) between calls and plans.
The upshot is that the only thread-safe routine in FFTW is
'fftw_execute' (and the new-array variants thereof). All other routines
(e.g. the planner) should only be called from one thread at a time.
So, for example, you can wrap a semaphore lock around any calls to the
planner; even more simply, you can just create all of your plans from
one thread. We do not think this should be an important restriction
(FFTW is designed for the situation where the only performance-sensitive
code is the actual execution of the transform), and the benefits of
shared data between plans are great.
Note also that, since the plan is not modified by 'fftw_execute', it
is safe to execute the _same plan_ in parallel by multiple threads.
However, since a given plan operates by default on a fixed array, you
Execute Functions::) so that different threads compute the transform of
different data.
(Users should note that these comments only apply to programs using
shared-memory threads or OpenMP. Parallelism using MPI or forked
processes involves a separate address-space and global variables for
each process, and is not susceptible to problems of this sort.)
The FFTW planner is intended to be called from a single thread. If
you really must call it from multiple threads, you are expected to grab
whatever lock makes sense for your application, with the understanding
that you may be holding that lock for a long time, which is undesirable.
Neither strategy works, however, in the following situation. The
"application" is structured as a set of "plugins" which are unaware of
each other, and for whatever reason the "plugins" cannot coordinate on
grabbing the lock. (This is not a technical problem, but an
organizational one. The "plugins" are written by independent agents,
and from the perspective of each plugin's author, each plugin is using
FFTW correctly from a single thread.) To cope with this situation,
starting from FFTW-3.3.5, FFTW supports an API to make the planner
thread-safe:
void fftw_make_planner_thread_safe(void);
This call operates by brute force: It just installs a hook that wraps
a lock (chosen by us) around all planner calls. So there is no magic
and you get the worst of all worlds. The planner is still
single-threaded, but you cannot choose which lock to use. The planner
still holds the lock for a long time, but you cannot impose a timeout on
lock acquisition. As of FFTW-3.3.5 and FFTW-3.3.6, this call does not
work when using OpenMP as threading substrate. (Suggestions on what to
do about this bug are welcome.) _Do not use
'fftw_make_planner_thread_safe' unless there is no other choice,_ such
as in the application/plugin situation.
Info Catalog
fftw3: How Many Threads to Use?
fftw3: Multi-threaded FFTW