ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

STL线程安全性讨论

2022-02-06 17:04:14  阅读:170  来源: 互联网

标签:map 加锁 容器 STL vector 线程 安全性 resize


STL容器不是线程安全的。对于vector,即使写方(生产者)是单线程写入,但是并发读的时候,由于潜在的内存重新申请和对象复制问题,会导致读方(消费者)的迭代器失效。实际表现也就是招致了core dump。另外一种情况,如果是多个写方,并发的push_back(),也会导致core dump。

解法一:

加锁是一种解决方案,但是加std::mutex互斥锁性能较差。对于多读少写的场景可以用读写锁(也叫共享独占锁),来缓解。C++17引入了std::shared_mutex(shared_mutex的适用场景比较特殊:一个或多个读线程同时读取共享资源,且只有一个写线程来修改这个资源,这种情况下才能从shared_mutex获取性能优势。) 。更多锁的种类可以阅读下面这篇回答,但是本回答的目的自然不是自我重复再次介绍一次锁的使用,请继续阅读解法二!

作者:果冻虾仁
链接:https://www.zhihu.com/question/29987589/answer/1483744520
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

解法二:

更多的时候,其实可以通过固定vector的大小,避免动态扩容(无push_back)来做到lock-free

即在开始并发读写之前(比如初始化)的时候,给vector设置好大小。

struct Data {
...
};
vector<Data> v;
v.resize(1000);

注意是resize,不是reserve!

可能大家平时用reserve()比较多,顾名思义,reserve就是预留内存。为的是避免内存重新申请以及容器内对象的拷贝。说白了,reserve()是给push_back()准备的!

resize除了预留内存以外,还会调用容器元素的构造函数,不仅分配了N个对象的内存,还会构造N个对象。从这个层面上来说,resize()在时间效率上是比reserve()低的。但是在多线程的场景下,用resize再合适不过。

你可以resize好N个对象,多线程不管是读还是写,都是通过容器的下标访问【operator[]】来访问元素,不要push_back新元素。所谓的『写操作』在这里不是插入新元素,而是修改旧元素。

如果N的最大个数是可以预期的就直接设置就好,如果没办法预期就再把vector搞成ring buffer(环形队列)来缓解压力

可以给元素类加上成员变量标记当前的读写状态、是否被消费等等

当然,你会说,如果B,C,D,E,F这个5个线程是等价的,要不停消费vector中的元素,会造成重复消费不?

当然会。你可以把 队列头的下标定义程原子变量(std::atomic),尽管原子变量也需要做线程同步,但是比一般的锁开销要小很多啦。

如果你想连原子变量也不用,有没有办法呢?有啊。那就给B,C,D,E,F分配不同的消费队列啊。比如当前有5个读线程,那么每个线程就消费下标模5之后的某个固定结果的下标。比如:

  • B消费:0、5、10、15、……
  • C消费:1、6、11、16、……
  • D消费:2、7、12、17、……
  • E消费:3、8、13、18、……
  • F消费:4、9、14、19、……

每个读线程各自维护自己当前消费的最新下标。

这样做有啥问题没?也有,就是可能会导致不同的线程繁忙和等待的情况差异巨大:忙的忙死,闲的闲死。具体场景具体分析,总之,无论如何要控制住。不要让一个任务hang住整个线程。

关联容器的线程安全问题

vector是顺序容器,STL中还有一类关联容器其线程安全问题也不容小觑。比如map、unordered_map。

我们可能会有这样一种场景:在并发环境下,收集一些Key-Value,存储在某一个公共的容器中。这里也谈一下不用锁的方案,当然做不到放之四海皆准。它有一些限制条件,只能看是否满足你的需要了。

当有多个写线程对情况下,并发地插入 map/unordered_map都会引发core dump。对此,在某些场景下也可以避免加锁:如果全量的key有办法在并发之前就能拿到的,那么就对这个map,提前做一下insert。并发环境中如果只是修改value,而不是插入新key就不会core dump!不过如果你没办法保证多个写线程不会同时修改同一个key的value,那么可能存在value的覆盖。无法保证这点时,还是需要加锁。不过可以对key采取某种hash策略转成整型,然后进行分段加锁,减少一点锁冲突的概率,或者用一下CAS的策略

另外对于map,在单写多读到场景下,问题其实不大。至少不会core dump,你唯一需要避免的就是重复消费/写覆盖的问题。同样可以实施对key的分段加锁,或采用CAS策略

 

标签:map,加锁,容器,STL,vector,线程,安全性,resize
来源: https://www.cnblogs.com/guxuanqing/p/14830321.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有