【问题描述】
使用FFTW库，然后应用程序使用存在多线程的情况下，会出现信号11 或者 信号6等一些内存问题。
【根本原因】
查阅官方文档
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 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.
(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.
简单的说就是针对多线程使用的场景，有2种方案
- 使用官方推荐的带有安全线程的函数API接口
- 使用锁保护资源
因为很多函数接口都是不可重入的
【解决办法】
针对多线程FFTW的不可重入函数加入互斥锁保护