d@0: d@0: Previous: How Many Threads to Use?, d@0: Up: Multi-threaded FFTW d@0:
Users writing multi-threaded programs must concern themselves with the d@0: thread safety of the libraries they use—that is, whether it is d@0: safe to call routines in parallel from multiple threads. FFTW can be d@0: used in such an environment, but some care must be taken because the d@0: planner routines share data (e.g. wisdom and trigonometric tables) d@0: between calls and plans. d@0: d@0:
The upshot is that the only thread-safe (re-entrant) routine in FFTW is
d@0: fftw_execute (and the new-array variants thereof). All other routines
d@0: (e.g. the planner) should only be called from one thread at a time. So,
d@0: for example, you can wrap a semaphore lock around any calls to the
d@0: planner; even more simply, you can just create all of your plans from
d@0: one thread. We do not think this should be an important restriction
d@0: (FFTW is designed for the situation where the only performance-sensitive
d@0: code is the actual execution of the transform), and the benefits of
d@0: shared data between plans are great.
d@0:
d@0:
Note also that, since the plan is not modified by fftw_execute,
d@0: it is safe to execute the same plan in parallel by multiple
d@0: threads. However, since a given plan operates by default on a fixed
d@0: 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.
d@0:
d@0:
(Users should note that these comments only apply to programs using d@0: shared-memory threads. Parallelism using MPI or forked processes d@0: involves a separate address-space and global variables for each process, d@0: and is not susceptible to problems of this sort.) d@0: d@0: d@0: d@0: