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