Question

我决定并行化我编写的一个庞大的程序，最终我遇到了新的C ++ 11智能指针。

我有一个应该被执行多次（通常超过1000次）的例程，这有点贵。它是在一个简单的for循环中运行的，我所做的是在一个方法中安装这个for循环，该方法将由一些工作线程运行。

这样做了，一些参数被std::shared_ptr包裹起来，关心竞争条件，一切似乎都很好。

但是现在，有些时候，流程将被中止，我会收到以下错误之一：

处理以退出代码139结束（由信号11中断： SIGSEGV）

或

malloc.c：2395：sysmalloc：断言`（old_top == initial_top（av）＆amp;＆amp; old_size == 0）|| （（unsigned long）（old_size）＆gt; = MINSIZE＆amp;＆amp; prev_inuse （old_top）＆amp;＆amp; （（unsigned long）old_end＆amp;（pagesize - 1））== 0）＆＃39;失败。

当并行正在进行时，所有这些错误都会发生;不是之前，不是在开头，不是在最后，而是介于两者之间，这让我闻起来就像一场未被覆盖的竞争条件。

程序很大，但我创建了一个能够重现问题的缩影：

#include <iostream>
#include <vector>
#include <unordered_map>
#include <thread>
#include <set>
#include <memory>
#include <atomic>

namespace std {
    template <>
    struct hash<std::multiset<unsigned long>>
    {
        std::size_t operator()(const std::multiset<unsigned long>& k) const
        {
            std::size_t r = 0;

            bool shift = false;
            for (auto&& it : k) {
                r = (r >> !shift) ^ (std::hash<unsigned long>()(it) << shift);
                shift = !shift;
            }

            return r;
        }
    };
}

typedef std::unordered_map<std::multiset<unsigned long>, int*> graphmap;

std::multiset<unsigned long>* bar(int pos) {
    std::multiset<unsigned long> *label = new std::multiset<unsigned long>;

    label->insert(pos%5);
    label->insert(pos%2);

    return label;
}

void foo(std::shared_ptr<graphmap> &kSubgraphs, int pos) {
    int *v = (*kSubgraphs)[*bar(pos)];

    if(v == nullptr) {
        v = new int[pos+1]();
        v[0]++;
    } else {
        v[pos]++;
    }
}

void worker(std::shared_ptr<std::atomic_int> *counter, int n, std::shared_ptr<graphmap> *kSubgraphs)
{
    for (int pos = (*counter)->fetch_add(1); pos <= n; pos = (*counter)->fetch_add(1)) {
        if (pos%100==0) std::cout << pos << std::endl;
        foo(*kSubgraphs, pos);
    }
}

int main() {
    int n = 1000;

    std::vector<std::thread> threads;
    std::shared_ptr<graphmap> kSubgraphs = std::make_shared<graphmap>();
    std::shared_ptr<std::atomic_int> counter = std::make_shared<std::atomic_int>(0);
    for (int i=0; i<5; i++) {
        foo(kSubgraphs, n);
    }

    for (int i=0; i<4; i++) {
        threads.push_back(std::thread(worker, &counter, n, &kSubgraphs));
    }

    for(auto& th : threads) th.join();

    return 0;
}

此代码基本上模仿原始代码的行为，即使用 multiset 键入的 unordered_map ，其值为指向 int em>数组。首先插入一些键并初始化数组（可能问题是由我初始化它的方式引起的？）最后工作线程运行以更新 unordered_map

两个线程可以同时访问同一个映射表项，但它们永远不会同时写入该数组的同一索引。

与原始代码不同，此代码在通过ideone.com等互联网编译器运行时不会抛出任何错误，我也尝试从CLion ide运行它并且不会发生错误（可能会发生错误如果一个人尝试了足够的次数），但是当从命令行多次运行时，我得到了与原始版本类似的错误。我编译它：

g++ -std=c++11 -pthread -o test.exe test.cpp

运行几次之后，最终会出现此错误：

*** Error in `./test.exe': double free or corruption (fasttop): 0x00000000006a2d30 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fccc9d4f725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fccc9d57f4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fccc9d5babc] ./test.exe[0x404e9e] ./test.exe[0x40431b] ./test.exe[0x4045ed] ./test.exe[0x407c6c] ./test.exe[0x4078d6] ./test.exe[0x40742a] ./test.exe[0x40869e] ./test.exe[0x4086be] ./test.exe[0x4085dd] ./test.exe[0x40842d] ./test.exe[0x4023a2] ./test.exe[0x401d55] ./test.exe[0x401c4a] ./test.exe[0x401c66] ./test.exe[0x401702] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fccc9cf8830] ./test.exe[0x401199] ======= Memory map: ======== 00400000-0040f000 r-xp 00000000 08:05 12202697 /home/rodrigo/test.exe 0060e000-0060f000 r--p 0000e000 08:05 12202697 /home/rodrigo/test.exe 0060f000-00610000 rw-p 0000f000 08:05 12202697 /home/rodrigo/test.exe 00691000-006c3000 rw-p 00000000 00:00 0 [heap] 7fcca8000000-7fcca8089000 rw-p 00000000 00:00 0 7fcca8089000-7fccac000000 ---p 00000000 00:00 0 7fccb0000000-7fccb008b000 rw-p 00000000 00:00 0 7fccb008b000-7fccb4000000 ---p 00000000 00:00 0 7fccb8000000-7fccb8089000 rw-p 00000000 00:00 0 7fccb8089000-7fccbc000000 ---p 00000000 00:00 0 7fccc0000000-7fccc007c000 rw-p 00000000 00:00 0 7fccc007c000-7fccc4000000 ---p 00000000 00:00 0 7fccc79cb000-7fccc79cc000 ---p 00000000 00:00 0 7fccc79cc000-7fccc81cc000 rw-p 00000000 00:00 0 7fccc81cc000-7fccc81cd000 ---p 00000000 00:00 0 7fccc81cd000-7fccc89cd000 rw-p 00000000 00:00 0 7fccc89cd000-7fccc89ce000 ---p 00000000 00:00 0 7fccc89ce000-7fccc91ce000 rw-p 00000000 00:00 0 7fccc91ce000-7fccc91cf000 ---p 00000000 00:00 0 7fccc91cf000-7fccc99cf000 rw-p 00000000 00:00 0 7fccc99cf000-7fccc9ad7000 r-xp 00000000 08:05 24126366 /lib/x86_64-linux-gnu/libm-2.23.so 7fccc9ad7000-7fccc9cd6000 ---p 00108000 08:05 24126366 /lib/x86_64-linux-gnu/libm-2.23.so 7fccc9cd6000-7fccc9cd7000 r--p 00107000 08:05 24126366 /lib/x86_64-linux-gnu/libm-2.23.so 7fccc9cd7000-7fccc9cd8000 rw-p 00108000 08:05 24126366 /lib/x86_64-linux-gnu/libm-2.23.so 7fccc9cd8000-7fccc9e98000 r-xp 00000000 08:05 24126374 /lib/x86_64-linux-gnu/libc-2.23.so 7fccc9e98000-7fccca097000 ---p 001c0000 08:05 24126374 /lib/x86_64-linux-gnu/libc-2.23.so 7fccca097000-7fccca09b000 r--p 001bf000 08:05 24126374 /lib/x86_64-linux-gnu/libc-2.23.so 7fccca09b000-7fccca09d000 rw-p 001c3000 08:05 24126374 /lib/x86_64-linux-gnu/libc-2.23.so 7fccca09d000-7fccca0a1000 rw-p 00000000 00:00 0 7fccca0a1000-7fccca0b9000 r-xp 00000000 08:05 24126373 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fccca0b9000-7fccca2b8000 ---p 00018000 08:05 24126373 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fccca2b8000-7fccca2b9000 r--p 00017000 08:05 24126373 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fccca2b9000-7fccca2ba000 rw-p 00018000 08:05 24126373 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fccca2ba000-7fccca2be000 rw-p 00000000 00:00 0 7fccca2be000-7fccca2d4000 r-xp 00000000 08:05 24121519 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fccca2d4000-7fccca4d3000 ---p 00016000 08:05 24121519 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fccca4d3000-7fccca4d4000 rw-p 00015000 08:05 24121519 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fccca4d4000-7fccca646000 r-xp 00000000 08:05 6029347 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fccca646000-7fccca846000 ---p 00172000 08:05 6029347 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fccca846000-7fccca850000 r--p 00172000 08:05 6029347 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fccca850000-7fccca852000 rw-p 0017c000 08:05 6029347 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 7fccca852000-7fccca856000 rw-p 00000000 00:00 0 7fccca856000-7fccca87c000 r-xp 00000000 08:05 24126370 /lib/x86_64-linux-gnu/ld-2.23.so 7fcccaa44000-7fcccaa4a000 rw-p 00000000 00:00 0 7fcccaa78000-7fcccaa7b000 rw-p 00000000 00:00 0 7fcccaa7b000-7fcccaa7c000 r--p 00025000 08:05 24126370 /lib/x86_64-linux-gnu/ld-2.23.so 7fcccaa7c000-7fcccaa7d000 rw-p 00026000 08:05 24126370 /lib/x86_64-linux-gnu/ld-2.23.so 7fcccaa7d000-7fcccaa7e000 rw-p 00000000 00:00 0 7ffc6b1c8000-7ffc6b1e9000 rw-p 00000000 00:00 0 [stack] 7ffc6b1fa000-7ffc6b1fc000 r--p 00000000 00:00 0 [vvar] 7ffc6b1fc000-7ffc6b1fe000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [1] 26639 abort (core dumped) ./test.exe

最后，当在CLion中运行调试模式的原始代码设置为将异常捕获为断点时，它会显示信号中断SIGBUS(Bus error)或SIGSEGV(Segmentation fault)有时和最后一行代码执行在中断映射到该行之前：

int *v = (*kSubgraphs)[*bar(pos)];

在此处提供的代码的foo函数中。

我对这个有点失落。我最强烈的假设是我使用智能指针是错误的，尽管我没有看到。

Answer 1

您的程序具有未定义的行为，因为您从不同的线程访问kSubgraphs指向的对象而没有互斥。这发生在函数foo中的这行代码中，它是从您的线程函数worker调用的：

int *v = (*kSubgraphs)[*bar(pos)];

我猜不出为什么你认为shared_ptr会以任何方式帮助你的案子。按照你的方式，将对象包装在shared_ptr中是完全没有意义的。

当从不同的其他对象共享对象的所有权时，使用

shared_ptr。它与“在线程之间共享对象”无关。

使用std :: shared_ptr

1 个答案: