c++ - OpenMP STL 集容器迭代器

Question

我遇到的问题与此处提出的问题类似 - OpenMP parallel thread .我希望并行化 for 循环涉及 std::set 迭代器。所以我正在尝试研究@Hristo lliev 提供的答案。我不太确定。

如果一个线程没有得到pick任务，那么它的“worst_q”应该是它进入临界区时的原始数。但是如果一个线程选择了一个任务，并且任务内部的“t_worst_q”将被更改，那么当这个线程进入临界区时，这个“t_worst_q”将保持与任务构造中的相同，我说得对吗？但是，我用了一个例子，它并没有像这样出现，也许我仍然遗漏了一些东西。

Answer 1

是的，您解释它的方式就是“Hristo Iliev”希望它如何工作。不幸的是，他在一些关于任务的事情上犯了错误:

他使用 taskwait 的所谓“屏障”只对创建任务的线程有效。所有其他线程都通过它运行。所以他最终的整个减少是无用的，因为大多数线程在它们实际执行任何工作之前执行它。 “taskwait”旨在帮助解释数据依赖性(非常有用 in recursive functions !)，这就是它以这种方式工作的原因。

即使最终没有减少功能，程序有时仍能正常工作的唯一原因是他的第一个错误被第二个错误部分抵消了:任务中的变量 t_worst_q 引用了一个来自生成任务的线程，因此充当全局变量。但是，当然，我们在 std::min 中有一个竞争条件，这有时仍然会让代码失败。

因此实际上他的代码等同于以下内容:

#pragma omp parallel
{
   // Create tasks
   #pragma omp single nowait
   {
      for(std::set<size_t>::const_iterator it=mesh->NEList[vid].begin();
          it!=mesh->NEList[vid].end(); ++it) {
         size_t elem = *it;
         #pragma omp task shared(worst_q)
         worst_q = std::min(worst_q, mesh->element_quality(elem));
      }
   }
}

如前所述，在执行 std::min 时，存在访问 worst_q 时出现竞争条件的问题。如果函数 mesh->element_quality 与 std::min 函数相比计算量大，那么一个简单的解决方案是围绕 std::min 的临界区 部分(在临界区外执行了 mesh->element_quality 之后)。另一方面，如果 mesh->element_quality 并不比 std::min 更昂贵，那么临界区将终止并行性。但在这种情况下，函数 mesh->element_quality 非常便宜，以至于管理任务的开销无论如何都会吃掉所有潜在的加速。