cannam@127: Previous: How Many Threads to Use?, Up: Multi-threaded FFTW [Contents][Index]
cannam@127:Users writing multi-threaded programs (including OpenMP) must concern cannam@127: themselves with the thread safety of the libraries they cannam@127: use—that is, whether it is safe to call routines in parallel from cannam@127: multiple threads. FFTW can be used in such an environment, but some cannam@127: care must be taken because the planner routines share data cannam@127: (e.g. wisdom and trigonometric tables) between calls and plans. cannam@127:
cannam@127:The upshot is that the only thread-safe (re-entrant) routine in FFTW is
cannam@127: fftw_execute (and the new-array variants thereof). All other routines
cannam@127: (e.g. the planner) should only be called from one thread at a time. So,
cannam@127: for example, you can wrap a semaphore lock around any calls to the
cannam@127: planner; even more simply, you can just create all of your plans from
cannam@127: one thread. We do not think this should be an important restriction
cannam@127: (FFTW is designed for the situation where the only performance-sensitive
cannam@127: code is the actual execution of the transform), and the benefits of
cannam@127: shared data between plans are great.
cannam@127:
Note also that, since the plan is not modified by fftw_execute,
cannam@127: it is safe to execute the same plan in parallel by multiple
cannam@127: threads. However, since a given plan operates by default on a fixed
cannam@127: array, you need to use one of the new-array execute functions (see New-array Execute Functions) so that different threads compute the transform of different data.
cannam@127:
(Users should note that these comments only apply to programs using cannam@127: shared-memory threads or OpenMP. Parallelism using MPI or forked processes cannam@127: involves a separate address-space and global variables for each process, cannam@127: and is not susceptible to problems of this sort.) cannam@127:
cannam@127:If you are configured FFTW with the --enable-debug or
cannam@127: --enable-debug-malloc flags (see Installation on Unix),
cannam@127: then fftw_execute is not thread-safe. These flags are not
cannam@127: documented because they are intended only for developing
cannam@127: and debugging FFTW, but if you must use --enable-debug then you
cannam@127: should also specifically pass --disable-debug-malloc for
cannam@127: fftw_execute to be thread-safe.
cannam@127:
Starting from FFTW-3.3.5, FFTW supports a new API to make the cannam@127: planner thread-safe: cannam@127:
void fftw_make_planner_thread_safe(void); cannam@127:
This call installs a hook that wraps a lock around all planner calls.
cannam@127: This API is meant for “applications” that use “plugins” in multiple
cannam@127: threads, where each “plugin” calls single-threaded FFTW but is unaware
cannam@127: of the other “plugins” doing the same thing at the same time. In this
cannam@127: case, the “application” calls fftw_make_planner_thread_safe()
cannam@127: at the beginning to protect “plugins” from each other.
cannam@127:
cannam@127: Previous: How Many Threads to Use?, Up: Multi-threaded FFTW [Contents][Index]
cannam@127: