C++ 如何在Cilk Plus中组织非线程安全资源池（每个工作人员一个资源）？

我有一个串行代码，我想使用Cilk Plus并行化；主循环对不同的数据集重复调用处理函数，因此迭代彼此独立，但使用非线程安全资源除外，该资源被封装到外部库提供的类（例如，

nts

）中，外部库接受文件名并对其进行I/O

如果我使用的是OpenMP，我会创建一个资源池，其中包含与线程数量相同的资源，并根据线程ID访问这些资源：

std:：vector nts\u池；
对于（std:：size_t i{0}；i

使用Cilk Plus，我可以使用

\uCilkrts\uGet\uWorkers（）

和

\uCilkrts\uGet\uWorker\uNumber（）

API做同样多的事情，但从英特尔论坛上的多篇帖子中，我发现这被认为是解决问题的错误方法，正确的解决方案是使用holder超对象

现在，holder解决方案看起来确实不错，只是我真的希望创建的视图数量与工作线程数量相同。也就是说，对于3个工作线程，我希望有3个对象，而不是更多。理由是，正如我所说，资源是由第三方库提供的，构建成本非常高，而且我必须在事后处理生成的文件，所以越少越好

不幸的是，我发现持有者不是按照每个工作者创建一个视图并将其保持到同步，而是按照我不理解的逻辑创建和销毁视图，而且似乎没有办法影响这种行为

有可能让持有者按照我想要的方式行事吗？如果没有，我的问题的惯用Cilk Plus解决方案是什么

这是我用来调查持有者的程序，请注意，它在一次运行期间在我的测试机器上创建了多达50个视图，这些视图似乎是随机分配和销毁的：

#包括
#包括
#包括
#包括
#包括
#包括
cilk：：异径光纤*超导体；
nts类{
公众：
nts（）：标记{std:：to_字符串（++id）}{
*hyper\u cout对于这个特定问题，持有者是一个诱人但效率低下的解决方案，这一点是正确的。如果您的程序正确地使用了插槽数组，每个工作线程有一个插槽，那么使用
\u cilkrts\u get\u workers（）
和
\u cilkrts\u get\u worker\u number（）确实没有什么问题
API在这种情况下。我们确实不鼓励一般情况下使用它们；更喜欢编写Cilk Plus代码，而不考虑工作人员的数量，因为这样通常可以更好地扩展。但是，在有些情况下，包括这一种情况，为每个工作人员创建一个槽是最好的策略。
非常感谢您给出明确的答案；在这种情况下，我会这样做选择我的插槽阵列解决方案！但是，如果您能进一步澄清为什么持有者的行为方式与当前的行为方式相同，我将不胜感激。这对我来说尤其违反直觉，因为我想到的最简单的实现是插槽阵列…：-）持有者的行为方式的主要原因是历史性的：持有者是构建在减速器机制之上，该机制保留关联操作的要求，即使所讨论的操作通常是no-op。正如您所发现的，这通常不是一个有用的属性，但它可以用于（例如）检测未更改的值，因此无需重新计算即可使用。我们正在查找在允许交换性的情况下，为减速器和保持架提供更有效的（即每个工人的插槽）机制。