C++ c++；具有共享指针的openmp_C++_Pointers_Openmp

C++ c++；具有共享指针的openmp

c++ pointers

C++ c++；具有共享指针的openmp,c++,pointers,openmp,C++,Pointers,Openmp,这里有一个最简单的例子来说明什么困扰着我 #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++){

这里有一个最简单的例子来说明什么困扰着我

#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>());
    }
}

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

编辑

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

我认为这取决于您的环境，它不相关，不应被视为奇怪的行为。使用MS VS 2015 preview，您的代码为我提供了以下信息（启用OMP）：

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

串行循环在每次迭代中，您都会得到一个在堆上创建的

，一个被销毁。这些操作的顺序如下所示：

建筑

毁灭

建筑

毁灭

。。。（等等）

由于

s是在堆上创建的，因此它们通过内存分配器。当内存分配器收到对新内存的请求（如步骤3所示）时，它（在许多情况下）将首先查看最近释放的内存。它看到最后一个操作是一个完全正确大小的内存释放（步骤2），因此将再次获取该内存块。此过程将在每次迭代中重复。因此，串行循环（通常但不一定）会一次又一次地给您相同的地址

并联回路现在让我们考虑一下并行循环。因为没有同步，所以内存分配和释放的顺序没有确定。因此，它们可以以任何你能想象的方式交错。因此，内存分配器通常不能像上次一样使用相同的技巧始终分配相同的内存。例如，排序的一个示例可能是，所有四个

s在全部被销毁之前都被构造—类似于这样：

建筑

毁灭

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

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

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

你所看到的行为一点也不奇怪，也不能保证。它取决于您拥有的物理内核数量、运行的线程数量、使用的迭代次数——通常是运行时条件

底线：一切都很好，你不应该读太多。

发帖后5秒的否决票？为什么？大多数时候我都会得到这样的结果，但有时我会得到我在问题中表现出来的那种结果。。。你试过多少次运行我的代码？只运行了10次我从未遇到过你的行为。你用什么？我将使用GCC进行尝试。我确实可以使用GCC4.9了解您的行为，但我不认为这是一种奇怪的行为。内存地址仍然有效。我想是的，我不明白为什么会有问题。让其他人确认一下：）回答得很好，谢谢。我现在可以理解为什么在串行版本中，它总是打印相同的东西，为什么在并行版本中它不打印。但这并不能解释为什么第四个cout包含14个字符，而树的first只包含8个字符（取自我的示例）。指针的长短“名称”是什么意思？那只是内存中的位置。堆栈位于内存空间的顶部，向下增长。一个长地址意味着堆位置是在靠近堆栈的地方找到的。

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