Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: FFTW 3.3.5: Thread safety Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: Chris@42:
Chris@42:

Chris@42: Previous: , Up: Multi-threaded FFTW   [Contents][Index]

Chris@42:
Chris@42:
Chris@42: Chris@42:

5.4 Thread safety

Chris@42: Chris@42: Chris@42: Chris@42: Chris@42:

Users writing multi-threaded programs (including OpenMP) must concern Chris@42: themselves with the thread safety of the libraries they Chris@42: use—that is, whether it is safe to call routines in parallel from Chris@42: multiple threads. FFTW can be used in such an environment, but some Chris@42: care must be taken because the planner routines share data Chris@42: (e.g. wisdom and trigonometric tables) between calls and plans. Chris@42:

Chris@42:

The upshot is that the only thread-safe (re-entrant) routine in FFTW is Chris@42: fftw_execute (and the new-array variants thereof). All other routines Chris@42: (e.g. the planner) should only be called from one thread at a time. So, Chris@42: for example, you can wrap a semaphore lock around any calls to the Chris@42: planner; even more simply, you can just create all of your plans from Chris@42: one thread. We do not think this should be an important restriction Chris@42: (FFTW is designed for the situation where the only performance-sensitive Chris@42: code is the actual execution of the transform), and the benefits of Chris@42: shared data between plans are great. Chris@42:

Chris@42:

Note also that, since the plan is not modified by fftw_execute, Chris@42: it is safe to execute the same plan in parallel by multiple Chris@42: threads. However, since a given plan operates by default on a fixed Chris@42: 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. Chris@42:

Chris@42:

(Users should note that these comments only apply to programs using Chris@42: shared-memory threads or OpenMP. Parallelism using MPI or forked processes Chris@42: involves a separate address-space and global variables for each process, Chris@42: and is not susceptible to problems of this sort.) Chris@42:

Chris@42:

If you are configured FFTW with the --enable-debug or Chris@42: --enable-debug-malloc flags (see Installation on Unix), Chris@42: then fftw_execute is not thread-safe. These flags are not Chris@42: documented because they are intended only for developing Chris@42: and debugging FFTW, but if you must use --enable-debug then you Chris@42: should also specifically pass --disable-debug-malloc for Chris@42: fftw_execute to be thread-safe. Chris@42:

Chris@42:

Starting from FFTW-3.3.5, FFTW supports a new API to make the Chris@42: planner thread-safe: Chris@42:

Chris@42:
void fftw_make_planner_thread_safe(void);
Chris@42: 
Chris@42: Chris@42: Chris@42:

This call installs a hook that wraps a lock around all planner calls. Chris@42: This API is meant for “applications” that use “plugins” in multiple Chris@42: threads, where each “plugin” calls single-threaded FFTW but is unaware Chris@42: of the other “plugins” doing the same thing at the same time. In this Chris@42: case, the “application” calls fftw_make_planner_thread_safe() Chris@42: at the beginning to protect “plugins” from each other. Chris@42:


Chris@42:
Chris@42:

Chris@42: Previous: , Up: Multi-threaded FFTW   [Contents][Index]

Chris@42:
Chris@42: Chris@42: Chris@42: Chris@42: Chris@42: