多线程资源抢占bug解决

bug说明

最近调试程序，程序在Release版本下可运行，一直没有问题，在Debug模式下编译后，就会报错。

但是如果将 DEBUG 的编译条件 由“-Og”改成 “-O2” 或者 “-O3”，即增大系统的优化力度，该报错又没有了。

原因排查

通过一系列排查，最终发现

• 获取id的时候const auto &id = pt2idx[global_id];，循环中多个global_id为0，从而得到的label[id]的值为0，计算randy_id的时候uint32_t randy_id = label[id] - 1;，因为是无符号的，所以 0 - 1 得到一个很大的值，造成了通过randy_id再取值的时候数组越界。

• 追根溯源，发现pt2idx[global_id]的值是在前一函数中多个线程中赋值的。打印日志发现，因为没有加锁，导致多个线程同时写入的时候发生了资源抢占。

但是pt2idx数组，已经提前申请好了一个很大的空间，理论上来说，多个线程依次向数组中填值即可，可是Debug模式下就会有问题。

因此解决资源抢占问题即可。

解决

后台有朋友说，直接加锁不就行了吗？

是的，加锁是可以直接解决问题。但有时候加锁会造成单一线程写入的时候，其他线程都在等待的问题，所以效率和时间得需要根据具体场景制定。

现在来看看不加锁如何解决这种多线程写入问题。

资源抢占都是对公共变量或公共数组写入的时候发生的，因为归根到底还是对公共资源的竞争。

就像球场上，大家都在争夺1个球，都想控球，完成自己的任务，这就是资源抢占。有“资深球迷”就会说了，大家打球这么辛苦，这么多人玩1个球，如果每人发一个球，不就不抢了吗？这当然是个冷笑话，不过思路已经很明显了，为每个人配个球。

解决办法:

为每个线程配备一个数组，每个线程将global_id写入自己的数组，线程结束后，再对各个线程的global_id 数组进行合并

这里线程开启前，声明了1个std::vector<std::vector<int32_t>>，第1层vector是按照线程个数分配的，第2层vector是每个线程单独使用自己的数组 std::vector<int32_t>，这样就不会造成资源抢占了

// 线程开始之前
const uint32_t TotalThreadNum = 10;
std::vector<std::vector<int32_t>> threads_ids(TotalThreadNum);

// 线程内部
auto &arr_ids = threads_ids[i]; // i 为 线程序号
arr_ids.emplace_back(global_id);

最后对每个线程获取到的 global_id数组进行合并，因为是顺序访问数组，所以速度会很快

经验

• 避免多线程资源抢占，可以加锁，加锁后各线程不抢占资源，每次允许1个线程读写数据；

#include <mutex>
 mutable std::mutex mutex_;
std::lock_guard<std::mutex> lock(mutex_);

• 避免多线程同时访问公共变量，读取可以，如果写入，必须明确写入的位置，如果容器是动态分配的，事先也不知道要向公共容器里写入多少数据，可以为每个线程分配单独的容器，最后再合并。

• 使用加锁或者不加锁的方法，需要权衡加锁的等待的代价和不加锁最终统一拷贝的代价，不同场景需要不同配置

---

>>>>> 欢迎关注公众号【三戒纪元】 <<<<<