Loading...
墨滴

果冻

2021/10/09  阅读:26  主题:自定义主题1

当我们谈论shared_ptr的线程安全性时,我们在谈论什么

自C++11起,shared_ptr从boost转正进入标准库已有10年了。然而当C++程序员们在谈论shared_ptr是不是线程安全的的时候,还时常存在分歧。确实关于shared_ptr 的线程安全性不能直接了当地用安全或不安全来简单回答的,下面我来探讨一下。

线程安全的定义

先回顾一下线程安全这一概念的定义,以下摘录自维基百科:

Thread safety is a computer programming concept applicable to multi-threaded code. Thread-safe code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction. There are various strategies for making thread-safe data structures.

主要表达的就是多线程操作一个共享数据的时候,能够保证所有线程的行为是符合预期的。

一般而言线程不安全的行为大多数出现了data race导致的,比如你调用了某个系统函数,而这个函数内部其实用到了静态变量,那么多线程执行该函数的时候,就会触发data race,造成结果不符合预期,严重的时候,甚至会导致core dump。

当然这里只是一个例子,线程不安全还可能由其他原因导致。

你认为shared_ptr有哪些线程安全隐患?

shared_ptr 可能的线程安全隐患大概有如下几种,一是引用计数的加减操作是否线程安全,二是shared_ptr修改指向时,是否线程安全。另外shared_ptr不是一个类,而是一个类模板,所以对于shared_ptr 的T的并发操作的安全性,也会被纳入讨论范围。因此造成了探讨其线程安全性问题上的复杂性。

引用计数的探讨

岔开个话题,前段时间我面试过几个校招生,每当我问道是否了解shared_ptr的时候,对方总能巴拉巴拉说出一大堆东西。会讲到引用计数、weak_ptr解决循环引用、自定义删除器的用法等等等等。感觉这些知识都是很八股的东西。我会立马打断去问一句:引用计数具体是怎么实现的?怎么做到多个shared_ptr之间的计数能共享,同步更新的呢?比如:

shared_ptr<A> sp1 = make_shared<A>();
...
shared_ptr<A> sp2 = sp1;
...
shared_ptr<A> sp3 = sp1;

当sp3出现的时候,sp2怎么感知到计数又加1了的呢?这时候很多学生都会卡住,犯了难。有的同学确实没有了解过的,就盲猜了一个,答道:用static变量存储的引用计数。

答案当然是否定的,因为如果是static变量的话,那么:

shared_ptr<A> sp1 = make_shared<A>();
shared_ptr<A> sp2 = make_shared<A>();

这两个不相干的sp1和sp2,只要模板参数T是同一个类型,就会共享同一个计数…

可以看下cppreference的描述:

https://en.cppreference.com/w/cpp/memory/shared_ptr#Implementation_notes

shared_ptr中除了有一个指针,指向所管理数据的地址。还有一个指针执行一个控制块的地址,里面存放了所管理数据的数量(常说的引用计数)、weak_ptr的数量、删除器、分配器等。

也就是说对于引用计数这一变量的存储,是在堆上的,多个shared_ptr的对象都指向同一个堆地址。在多线程环境下,管理同一个数据的shared_ptr在进行计数的增加或减少的时候是线程安全的吗?

答案是肯定的,这一操作是原子操作。

To satisfy thread safety requirements, the reference counters are typically incremented using an equivalent of std::atomic::fetch_add with std::memory_order_relaxed (decrementing requires stronger ordering to safely destroy the control block)

修改指向时是否是线程安全

这个要分情况来讨论:

情况一:多线程代码操作的是同一个shared_ptr的对象

比如std::thread的回调函数,是一个lambda表达式,其中引用捕获了一个shared_ptr对象

    std::thread td([&sp1] () {....});

又或者通过回调函数的参数传入的shared_ptr对象,参数类型是引用:

void fn(shared_ptr<A>& sp) {
    ...
}
...
    std::thread td(fn, sp1);

这时候确实是不是线程安全的。

当你在多线程回调中修改shared_ptr指向的时候。

void fn(shared_ptr<A>& sp) {
    ...
    if (..) {
        sp = other_sp;
    } else if (...) {
        sp = other_sp2;
    }
}

shared_ptr内数据指针要修改指向,sp原先指向的引用计数的值要减去1,other_sp指向的引用计数值要加1。然而这几步操作加起来并不是一个原子操作,如果多少线程都在修改sp的指向的时候,那么有可能会出问题。比如在导致计数在操作减一的时候,其内部的指向,已经被其他线程修改过了。引用计数的异常会导致某个管理的对象被提前析构,后续在使用到该数据的时候触发core dump。

当然如果你没有修改指向的时候,是没有问题的。

情况二:多线程代码操作的不是同一个shared_ptr的对象

这里指的是管理的数据是同一份,而shared_ptr不是同一个对象。比如多线程回调的lambda的是按值捕获的对象。

    std::thread td([sp1] () {....});

或者参数传递的shared_ptr是值传递,而非引用:

void fn(shared_ptr<A> sp) {
    ...
}
...
    std::thread td(fn, sp1);

这时候每个线程内看到的sp,他们所管理的是同一份数据,用的是同一个引用计数。但是各自是不同的对象,当发生多线程中修改sp指向的操作的时候,是不会出现非预期的异常行为的。

也就是说,如下操作是安全的:

void fn(shared_ptr<A> sp) {
    ...
    if (..) {
        sp = other_sp;
    } else if (...) {
        sp = other_sp2;
    }
}

所管理数据的线程安全性

尽管前面我们提到了如果是按值捕获(或传参)的shared_ptr对象,那么是该对象是线程安全的。然而话虽如此,但却可能让人误入歧途。因为我们使用shared_ptr更多的是操作其中的数据,对齐管理的数据进行读写。尽管在按值捕获的时候shared_ptr是线程安全的,我们不需要对此施加额外的同步操作(比如加解锁),但是这并不意味着shared_ptr所管理的对象是线程安全的!

请注意这是两回事。

如果shared_ptr管理的数据是STL容器,那么多线程如果存在同时修改的情况,是极有可能触发core dump的。比如多个线程中对同一个vector进行push_back,或者对同一个map进行了insert。甚至是对STL容器中并发的做clear操作,都有可能出发core dump,当然这里的线程不安全性,其实是其所指向数据的类型的线程不安全导致的,并非是shared_ptr本身的线程安全性导致的。尽管如此,由于shared_ptr使用上的特殊性,所以我们有时也要将其纳入到shared_ptr相关的线程安全问题的讨论范围内。

这里简单提一下,除了STL容器的并发修改操作(这里指的是修改容器的结构,并不是修改容器中某个元素的值,后者是线程安全的,前者不是),protobuf的Message对象也是不能并发操作的,比如一个线程中修改Message对象(set、add、clear),另外一个线程也在修改,或者在将其序列化成字符串都会触发core dump。据我的工作经验,由于程序出现了非预期地并发修改容器对象或PB的Message对象的操作导致的core dump问题,在所有core dump事故原因中的占比是相当大的。

不管是STL容器或是PB的Message对象,如果无脑地加锁,当然会解决其潜在的core dump问题。但是效率并不一定高,关于STL容器在某些场景下可以规避掉该隐患,笔者曾经回答过一个相关的问题,有兴趣可以了解:

C++ STL容器如何解决线程安全的问题?394 赞同 · 32 评论回答

除上述回答中提到的一些观点之外呢,有时候调整程序的逻辑,或许能更为优雅的解决问题。

比如我曾经见过的一段代码,一次请求过程中要异步查询Redis的两个key,在异步的回调函数中对查询到的value进行处理。,有一个处理逻辑是根据查到的value值,去判断是否满足一个条件,然后清空一个unordere_map的变量(调用clear成员函数)。这两个回调函数中都有可能会触发这个clear操作。然而这个代码在测试中出现了core dump。原因就是这个clear可能同时触发,对同一个unordere_map对象进行clear,是会出现这个问题的。

修改办法就是,新增两个bool类型的flag变量,初始为false,两个异步回调函数中判断满足原先的条件后,各自修改不同的flag为true。

在后续的串行操作中(异步回调结束后)判断这两个flag,有一个为true就进行unordere_map对象的clear。

这里扯的有点远了,已经不是shared_ptr本身的讨论范围了,更多是讨论解决容器本身并发问题的办法。请注意你写的是C++代码,性能是很重要的,不要无脑加锁!

往期推荐

bthread源码剖析: 基本概念与TaskControl初始化
bthread源码剖析: 基本概念与TaskControl初始化
我是如何走向计算机这条路的?
我是如何走向计算机这条路的?
大学期间Linux C++后台开发这条线怎么走?
大学期间Linux C++后台开发这条线怎么走?
人生是一条蛇,它咬着自己的尾巴
人生是一条蛇,它咬着自己的尾巴

果冻

2021/10/09  阅读:26  主题:自定义主题1

作者介绍

果冻