多线程资源抢占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_);
-
避免多线程同时访问公共变量,读取可以,如果写入,必须明确写入的位置,如果容器是动态分配的,事先也不知道要向公共容器里写入多少数据,可以为每个线程分配单独的容器,最后再合并。
-
使用加锁或者不加锁的方法,需要权衡加锁的等待的代价和不加锁最终统一拷贝的代价,不同场景需要不同配置