Item 16: 让const成员函数做到线程安全
2016-02-05 10:52
471 查看
本文翻译自《effective modern C++》,由于水平有限,故无法保证翻译完全正确,欢迎指出错误。谢谢!
如果我们在数学领域里工作,我们可能会发现用一个类来表示多项式会很方便。在这个类中,如果有一个函数能计算多选式的根(也就是,多项式等于0时,各个未知量的值)将变得很方便。这个函数不会改变多项式,所以很自然就想到把它声明为const:
计算多项式的根代价可能很高,所以如果不必计算的话,我们就不想计算。如果我们必须要计算,那么我们肯定不想多次计算。因此,当我们必须要计算的时候,我们将计算后的多项式的根缓存起来,并且让roots函数返回缓存的根。这里给出最基本的方法:
概念上来说,roots的操作不会改变Polynomial对象,但是,对于它的缓存行为来说,它可能需要修改rootVals和rootsAreValid。这就是mutable很经典的使用情景,这也就是为什么这些成员变量的声明带有mutable。
现在想象一下有两个线程同时调用同一个Polynomial对象的roots:
客户代码是完全合理的,roots是const成员函数,这就意味着,它表示一个读操作。在多线程中非同步地执行一个读操作是安全的。至少客户是这么假设的。但是在这种情况下,却不是这样,因为在roots中,这两个线程中的一个或两个都可能尝试去修改成员变量rootsAreValid和rootVals。这意味着这段代码在没有同步的情况下,两个不同的线程读写同一段内存,这其实就是data race的定义。所以这段代码会有未定义的行为。
现在的问题是roots被声明为const,但是它却不是线程安全的。这样的const声明在C++11和C++98中都是正确的(取多项式的根不会改变多项式的值),所以我们需要更正的地方是线程安全的缺失。
解决这个问题最简单的方式就是最常用的办法:使用一个mutex:
std::mutex m被声明为mutable,因为对它加锁和解锁调用的都不是const成员函数,在roots(一个const成员函数)中,如果不这么声明,m将被视为const对象。
值得注意的是,因为std::mutex是一个move-only类型(也就是,这个类型的对象只能move不能copy),所以把m添加到Polynomial中,会让Polynomial失去copy的能力,但是它还是能被move的。
在一些情况下,一个mutex是负担过重的。举个例子,如果你想做的事情只是计算一个成员函数被调用了多少次,一个std::atomic计数器(也就是,其它的线程保证看着它的(counter的)操作不中断地做完,看Item 40)常常是达到这个目的的更廉价的方式。(事实上是不是更廉价,依赖于你跑代码的硬件和标准库中mutex的实现)这里给出怎么使用std::atomic来计算调用次数的例子:
和std::mutex相似,std::atomic也是move-only类型,所以由于callCount的存在,Point也是move-only的。
因为比起mutex的加锁和解锁,对std::atomic变量的操作常常更廉价,所以你可能会过度倾向于std::atomic。举个例子,在一个类中,缓存一个“计算昂贵”的int,你可能会尝试使用一对std::atomic变量来代替一个mutex:
这能工作,但是有时候它会工作得很辛苦,考虑一下:
一个线程调用Widget::magicValue,看到cacheValid是false的,执行了两个昂贵的计算,并且把它们的和赋给cachedValue。
在这个时间点,第二个线程调用Widget::magicValue,也看到cacheValid是false的,因此同样进行了昂贵的计算(这个计算第一个线程已经完成了)。(这个“第二个线程”事实上可能是一系列线程,也就会不断地进行这昂贵的计算)
这样的行为和我们使用缓存的目的是相违背的。换一下cachedValue和CacheValid赋值的顺序可以消除这个问题(不断进行重复计算),但是错的更加离谱了:
想象一下cacheValid是false的情况:
一个线程调用Widget::magicValue,并且刚执行完:把cacheValid设置为true。
同时,第二个线程调用Widget::magicValue,然后检查cacheValid,发现它是true,然后,即使第一个线程还没有把计算结果缓存下来,它还是直接返回cachedValue。因此,返回的值是不正确的。
让我们吸取教训。对于单一的变量或者内存单元,它们需要同步时,使用std::atomic就足够了,但是一旦你需要处理两个或更多的变量或内存单元,并把它们视为一个整体,那么你就应该使用mutex。对于Widget::magicValue,看起来应该是这样的:
现在,这个Item是基于“多线程可能同时执行一个对象的const成员函数”的假设。如果你要写一个const成员函数,并且你能保证这里没有多于一个的线程会执行这个对象的cosnt成员函数,那么函数的线程安全就不重要了。举个例子,如果一个类的成员函数只是设计给单线程使用的,那么这个成员函数是不是线程安全就不重要了。在这种情况下,你能避免mutex和std::atomic造成的负担。以及免受“包含它们的容器将变成move-only”的影响。然而,这样的自由线程(threading-free)变得越来越不常见了,它们还将变得更加稀有。以后,const成员函数的多线程执行一定会成为主题,这就是为什么你需要确保你的const成员函数是线程安全的。
你要记住的事
让const成员函数做到线程安全,除非你确保它们永远不会用在多线程的环境下。
比起mutex,使用std::atomic变量能提供更好的性能,但是它只适合处理单一的变量或内存单元
如果我们在数学领域里工作,我们可能会发现用一个类来表示多项式会很方便。在这个类中,如果有一个函数能计算多选式的根(也就是,多项式等于0时,各个未知量的值)将变得很方便。这个函数不会改变多项式,所以很自然就想到把它声明为const:
[code]class Polynomial{ public: using RootsType = //一个存放多项式的根的数据结构 std::vector<double>; //(using的信息请看Item 9) ... RootsType roots() const; ... };
计算多项式的根代价可能很高,所以如果不必计算的话,我们就不想计算。如果我们必须要计算,那么我们肯定不想多次计算。因此,当我们必须要计算的时候,我们将计算后的多项式的根缓存起来,并且让roots函数返回缓存的根。这里给出最基本的方法:
[code]class Polynomial{ public: using RootsType = std::vector<double>; RottsType roots() const { if(!rootsAreValid){ //如果缓存不可用 ... //计算根,把它们存在rootVals中 rootsAreValid = true; } return rootVals; } private: mutable bool rootsAreValid{ false }; //初始化的信息看Item 7 mutable RootsType rootVals{}; };
概念上来说,roots的操作不会改变Polynomial对象,但是,对于它的缓存行为来说,它可能需要修改rootVals和rootsAreValid。这就是mutable很经典的使用情景,这也就是为什么这些成员变量的声明带有mutable。
现在想象一下有两个线程同时调用同一个Polynomial对象的roots:
[code]Polynomuial p; ... /*-------- 线程1 -------- */ /*-------- 线程2 -------- */ auto rootsOfP = p.roots(); auto valsGivingZero = p.roots();
客户代码是完全合理的,roots是const成员函数,这就意味着,它表示一个读操作。在多线程中非同步地执行一个读操作是安全的。至少客户是这么假设的。但是在这种情况下,却不是这样,因为在roots中,这两个线程中的一个或两个都可能尝试去修改成员变量rootsAreValid和rootVals。这意味着这段代码在没有同步的情况下,两个不同的线程读写同一段内存,这其实就是data race的定义。所以这段代码会有未定义的行为。
现在的问题是roots被声明为const,但是它却不是线程安全的。这样的const声明在C++11和C++98中都是正确的(取多项式的根不会改变多项式的值),所以我们需要更正的地方是线程安全的缺失。
解决这个问题最简单的方式就是最常用的办法:使用一个mutex:
[code]class Polynomial{ public: using RootsType = std::vector<double>; RottsType roots() const { std::lock_guard<std::mutex> g(m); //锁上互斥锁 if(!rootsAreValid){ //如果缓存不可用 ... rootsAreValid = true; } return rootVals; } //解开互斥锁 private: mutable std::mutex m; mutable bool rootsAreValid{ false }; mutable RootsType rootVals{}; };
std::mutex m被声明为mutable,因为对它加锁和解锁调用的都不是const成员函数,在roots(一个const成员函数)中,如果不这么声明,m将被视为const对象。
值得注意的是,因为std::mutex是一个move-only类型(也就是,这个类型的对象只能move不能copy),所以把m添加到Polynomial中,会让Polynomial失去copy的能力,但是它还是能被move的。
在一些情况下,一个mutex是负担过重的。举个例子,如果你想做的事情只是计算一个成员函数被调用了多少次,一个std::atomic计数器(也就是,其它的线程保证看着它的(counter的)操作不中断地做完,看Item 40)常常是达到这个目的的更廉价的方式。(事实上是不是更廉价,依赖于你跑代码的硬件和标准库中mutex的实现)这里给出怎么使用std::atomic来计算调用次数的例子:
[code]class Point { public: ... double distanceFromOrigin() const noexcept //noexcept的信息请看Item 14 { ++callCount; //原子操作的自增 return std::sqrt((x * x) + (y * y)); } private: mutable std::atomic<unsigned> callCount{ 0 }; };
和std::mutex相似,std::atomic也是move-only类型,所以由于callCount的存在,Point也是move-only的。
因为比起mutex的加锁和解锁,对std::atomic变量的操作常常更廉价,所以你可能会过度倾向于std::atomic。举个例子,在一个类中,缓存一个“计算昂贵”的int,你可能会尝试使用一对std::atomic变量来代替一个mutex:
[code]class Widget { public: ... int magicValue() const { if (cacheValid) return cachedValue; else{ auto val1 = expensiveComputation1(); auto val2 = expensiveComputation2(); cachedValue = val1 + val2; //恩,第一部分 cacheValid = true; //恩,第二部分 return cachedValue; } } private: mutable std::atomic<bool> cacheValid { false }; mutable std::atomic<int> cachedValue; };
这能工作,但是有时候它会工作得很辛苦,考虑一下:
一个线程调用Widget::magicValue,看到cacheValid是false的,执行了两个昂贵的计算,并且把它们的和赋给cachedValue。
在这个时间点,第二个线程调用Widget::magicValue,也看到cacheValid是false的,因此同样进行了昂贵的计算(这个计算第一个线程已经完成了)。(这个“第二个线程”事实上可能是一系列线程,也就会不断地进行这昂贵的计算)
这样的行为和我们使用缓存的目的是相违背的。换一下cachedValue和CacheValid赋值的顺序可以消除这个问题(不断进行重复计算),但是错的更加离谱了:
[code]class Widget { public: ... int magicValue() const { if (cacheValid) return cachedValue; else{ auto val1 = expensiveComputation1(); auto val2 = expensiveComputation2(); cacheValid = true; //恩,第一部分 return cachedValue = val1 + val2; //恩,第二部分 } } ... };
想象一下cacheValid是false的情况:
一个线程调用Widget::magicValue,并且刚执行完:把cacheValid设置为true。
同时,第二个线程调用Widget::magicValue,然后检查cacheValid,发现它是true,然后,即使第一个线程还没有把计算结果缓存下来,它还是直接返回cachedValue。因此,返回的值是不正确的。
让我们吸取教训。对于单一的变量或者内存单元,它们需要同步时,使用std::atomic就足够了,但是一旦你需要处理两个或更多的变量或内存单元,并把它们视为一个整体,那么你就应该使用mutex。对于Widget::magicValue,看起来应该是这样的:
[code]class Widget { public: ... int magicValue() const { std::lock_guard<std::mutex> guard(m); //锁住m if (cacheValid) return cachedValue; else{ auto val1 = expensiveComputation1(); auto val2 = expensiveComputation2(); cachedValue = val1 + val2; cacheValid = true; return cachedValue; } } //解锁m ... private: mutable std::mutex m; mutable int cachedValue; //不再是atomic了 mutable bool cacheValid { false }; };
现在,这个Item是基于“多线程可能同时执行一个对象的const成员函数”的假设。如果你要写一个const成员函数,并且你能保证这里没有多于一个的线程会执行这个对象的cosnt成员函数,那么函数的线程安全就不重要了。举个例子,如果一个类的成员函数只是设计给单线程使用的,那么这个成员函数是不是线程安全就不重要了。在这种情况下,你能避免mutex和std::atomic造成的负担。以及免受“包含它们的容器将变成move-only”的影响。然而,这样的自由线程(threading-free)变得越来越不常见了,它们还将变得更加稀有。以后,const成员函数的多线程执行一定会成为主题,这就是为什么你需要确保你的const成员函数是线程安全的。
你要记住的事
让const成员函数做到线程安全,除非你确保它们永远不会用在多线程的环境下。
比起mutex,使用std::atomic变量能提供更好的性能,但是它只适合处理单一的变量或内存单元
相关文章推荐
- EasyUi图标
- 从request获取各种路径总结
- 怎么实现iMindMap视图间的快速切换
- Linux脚本参数之if fi
- Item 15: 只要有可能,就使用constexpr
- jsp的页面包含——静态包含、动态包含
- 全面解析Linux的grep命令中正则表达式的用法
- Gatling官网教程翻译之Simulation Structure
- Item 14: 如果函数不会抛出异常就把它们声明为noexcept
- Item 13: 比起iterator优先使用const_iterator
- setitimer函数
- 关于spark运行FP-growth算法报错com.esotericsoftware.kryo.KryoException
- 订餐系统——Gridview、Repeater和DataList 区别
- Item 12: 把重写函数声明为“override”的
- Java [Leetcode 160]Intersection of Two Linked Lists
- 静态和动态断言调试
- Android缓存文件的存放
- 超棒的 15 款 Bootstrap UI 编辑器
- [0] CMake综述
- 欢迎使用CSDN-markdown编辑器