带有 shared_ptr 的 C++ openmp

Question

这是一个困扰我的最小例子

#include <iostream>
#include <memory>
#include"omp.h"

class A{
    public:
        A(){std::cout<<this<<std::endl;}
};

int main(){
#pragma omp parallel for 
    for(unsigned int i=0;i<4;i++){
        std::shared_ptr<A> sim(std::make_shared<A>());
    }
    for(unsigned int i=0;i<4;i++){
        std::shared_ptr<A> sim(std::make_shared<A>());
    }
}

如果我多次运行这段代码，我可能会得到这样的结果:

0xea3308
0xea32d8
0xea3338
0x7f39f80008c8
0xea3338
0xea3338
0xea3338
0xea3338

我意识到最后 4 个输出的数量总是相同的字符 (8)。但由于某种原因，它发生(不总是)一个或多个第四个输出包含更多 (14) 个字符。看起来像使用openmp 改变了指针的“性质”(这是我天真的理解)。但这种行为正常吗？我应该期待一些奇怪的行为吗？

编辑

here是一个现场测试，在稍微复杂一点的代码版本中显示了同样的问题

Answer 1

这种行为是完全合理的，让我们看看发生了什么。

串行循环

在每次迭代中，您都会得到一个在堆上创建的 A，一个正在被销毁。这些操作的顺序如下:

1. 施工
2. 破坏
3. 施工
4. 破坏
5. ...(等等)

因为 A 是在堆上创建的，所以它们通过内存分配器。当内存分配器在第 3 步中收到对新内存的请求时，它(在许多情况下)将首先查看最近释放的内存。它看到最后一个操作是一个没有完全正确大小的内存(第 2 步)，因此将再次占用该内存块。此过程将在每次迭代中重复。所以串行循环会(通常但不一定)一遍又一遍地给你相同的地址。

并行循环

现在让我们考虑一下并行循环。由于没有同步，因此无法确定内存分配和释放的顺序。因此，它们有可能以您能想象的任何方式交错。因此，内存分配器通常无法使用与上次相同的技巧来始终分配同一 block 内存。一个示例顺序可能是例如所有四个 A 在它们全部被销毁之前构建 - 像这样:

1. 施工
2. 施工
3. 施工
4. 施工
5. 破坏
6. 破坏
7. 破坏
8. 破坏

因此，内存分配器必须提供 4 block 全新的内存，然后才能取回一些并开始回收。

基于堆栈的版本的行为更具确定性，但可能取决于编译器优化。对于串行版本，每次创建/销毁对象时都会调整堆栈指针。由于中间没有发生任何事情，它将继续在同一位置创建。

对于并行版本，每个线程在共享内存系统中都有自己的堆栈。因此每个线程都会在不同的内存位置创建它的对象，并且不可能进行“回收”。

您所看到的行为绝不是奇怪的，或者就此而言是有保证的。这取决于您拥有的物理内核数量、运行的线程数、您使用的迭代次数——通常是运行时条件。

底线:一切都很好，您不应该过度解读。