使用 FFTW 的线程分段错误

Question

我们在 i.MX53（基于 Linux 的 SO）上有一个 C 软件，它必须计算 FFT；为此，我们采用了 FFTW 库。出于性能原因，我们决定使用单独的线程将 FFT 从主应用程序中分离出来。整个应用程序似乎可以正常工作，但一段时间后，我们在 fftwf_execute 的对应关系中出现了分段错误。我确信这一点，因为没有这个单一的指令，我们就没有分段错误。我们进行了几次尝试，但问题仍然存在。这里是线程函数的一部分：

void* vGestDiag_ThreadFFT( void* unused )
{
  Int32U idx = 0, idxI = 0, idxJ = 0, idxZ = 0, idxK = 0;
  Flo32 lfBufferAccm_chn01[LEN_BUFFER_SAMPLES];
  Flo32 lfBufferAccm_chn02[LEN_BUFFER_SAMPLES];
  Flo64 dblBufferFFT[LEN_BUFFER_SAMPLES];
  Int32U ulCntUtilSample = 0;
  float *in;
  fftwf_complex *out;
  fftwf_plan plan;
  /* other variables.... */

  /* Init */
  memset(lfBufferAccm_chn01, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo32));
  memset(lfBufferAccm_chn02, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo32));
  memset(dblBufferFFT, 0x00, LEN_BUFFER_SAMPLES*sizeof(Flo64));
  /* other local memsets .... */

  /* Inputs */
  pthread_mutex_lock(&lockIN);

  ulCntUtilSample = wulCntUtilSample;
  /* other inputs.... */    

  for (idxJ = 0; idxJ < ulCntUtilSample; idxJ++)
  {
    boBuffCirc_ReadBuffer(&wulBufferAcc01, &ulTmpValue);
    lfBufferAccm_chn01[idxJ] = (Flo32)((((Flo32)ulTmpValue - ACC_Q)/ACC_M) * ACC_U) * wlfSensAcc;

    boBuffCirc_ReadBuffer(&wulBufferAcc02, &ulTmpValue);
    lfBufferAccm_chn02[idxJ] = (Flo32)((((Flo32)ulTmpValue - ACC_Q)/ACC_M) * ACC_U) * wlfSensAcc;
  }

  pthread_mutex_unlock(&lockIN);

  /* --------- Plan FFT ------------------------- */

  in = (float*) fftwf_malloc(sizeof(float) * ulCntUtilSample);
  out = (fftwf_complex*) fftwf_malloc(sizeof(fftwf_complex) * ulCntUtilSample);

  fftwf_plan_with_nthreads(1);
  plan = fftwf_plan_dft_r2c_1d(ulCntUtilSample, in, out, FFTW_ESTIMATE); 


  for (idxI = 0; idxI <= 1; idxI++)
  {
    switch(idxI)
    {
      case 0:
        memcpy(in, lfBufferAccm_chn01, ulCntUtilSample*sizeof(float));
        break;

      case 1:
        memcpy(in, lfBufferAccm_chn02, ulCntUtilSample*sizeof(float));
        break;

      default:
        break;
    }

    /* --------- FFT ------------------------- */

    /* EXEC */
    fftwf_execute(plan);

    /* Complex -> Real */
    for (idxZ = 0; idxZ < ulCntUtilSample; idxZ++)
    {
      dblBufferFFT[idxZ] = cabs(out[idxZ]);
    }

    /* --------- End FFT ------------------------- */

    /* Post-Processing FFT */
    /* post-processing and outputs in module static variables, within mutex */
  }

  /* DEL plan */
  fftwf_destroy_plan(plan);
  fftwf_free(in); 
  fftwf_free(out);

  /* exit */
  pthread_exit(NULL);  
}

以“w”开头的变量是模块静态变量，LEN_BUFFER 相对于样本数量而言过大。 谢谢大家帮忙！！

Answer 1

这是我第一个涉及线程的项目，我的同事也没有很好的经验，所以我们没有考虑几个问题。第一个是 DETACHABLE 和 JOINABLE 之间的区别：我们的应用程序不必等待线程完成；确实这是导致我们进入线程的问题（主线程等待 FFT 完成很长时间，虽然这不是必需的）。我的 SW 的早期版本是默认的、可连接的，因此分配给线程的资源永远不会空闲。我们没有考虑的第二点是生成线程需要额外的资源。在我的 SW 的先前版本中，每次必须计算 FFT 时都会生成一个线程；在我们的应用程序中，大约每 10 秒或更长时间添加一次，因此显然不是关键；此外，最快的是 FFT 开始，用于 FFT 的数据越少（说来话长，但我们可以总结一下）；最后，互斥锁的使用和算法的逻辑显然保护了共享资源（从线程和主线程同时使用共享资源的可能性很小）。不幸的是，线程生成，在几个周期后使内存饱和（我们不是在 PC 上工作，而是在一个简单的微处理器上工作......），这就是分段错误的根源，所以我相信。

我是这样解决问题的：FFT线程是在应用程序启动时生成的，所以只生成一个线程，连同main.线程内是一个无限循环，它定期（目前比主循环快 4 倍）检查指示 FFT 请求的共享变量：如果为真，则线程在本地读取并复制包含 FFT 输入的共享内存和其他必需的参数。在处理结束时，输出保存在共享内存中，并设置另一个标志以指示 fft 可用的主循环。在线程和主线程中，每个共享数据都使用互斥锁进行 R/W 访问，并且只有线程使用的数据由互斥锁控制。线程被生成为可分离的，没有任何终止或退出，因为线程必须与主线程“永远”一起存在。昨天这个 SW 已经运行了几个小时没有问题（我已经手动停止了）并且还在压力条件下。