Effective Modern C++翻译系列之Item16

Item 16:Make const member functions thread safe.
如果我们工作在数学领域，也许我们会发现用一个类来代表多项式是很方便的。在这个类中，有可能有一个函数被用来计算多项式的root，例如，当多项式等于0时的值。这样的函数将不会修改多项式，所以很自然的我们会把他声明为const：
class Polynomial {
public:
using RootsType = //多项式等于0时保存着值的数据类型
std::vector<double>;
...
RootsType roots() const;
};
计算多项式的roots会很昂贵，所以如果不是我们必须要那么做，我们不会想做这件事。并且如果我们必须要做这件事，我们也不会想做第二次。我们会把多项式的roots存储起来，然后我们执行roots时会返回存储的值。下面是基本的实现：
class Polynomial {
public:
using RoosType = std::vector<double>;
RootsType roots() const
{
if(!rootsAreValid) { //如果没有存储该值，
... //计算roots，存储在rootVals中
rootsAreValid = true;
}
return rootVals;
}
private:
mutable bool rootsAreValid{ false };
mutable RootsType rootVals{ };
};
从概念上来讲，roots不会改变它操纵的Polynomial对象，但是，作为它存储活动的一部分，它也许需要修改rootVals和rootsAreValid。这是mutable一个典型的应用情况，这也是为什么它是这两个数据成员声明的一部分。
想象一下现在有两个线程同时调用Polynomial对象的roots函数：
Polynomial p;
...
/*-----------Thread 1-------------*/      /*------------Thread 2-----------*/
auto rootsOfP = p.roots(); auto valsGivingZero = p.roots();
这段客户代码有理有据，令人信服。roots是一个const成员函数，这意味着它代表了一个读操作。非同步多线程执行一个读操作是安全的。至少它应该是。这个例子中，却不是这样的，因为在roots中，一个或者两个线程也许要修改数据成员rootsAreValid和rootVals。这意味着这段代码可能有不同的线程非同步的读和写相同的内存，这被称为数据竞争。这段代码有着未定义的行为。
问题在于roots被声明为const，但是它不是线程安全的。c++11中的const声明和c++98中一样正确（恢复一个多项式的roots不会改变多项式的值），所以需要被修正的是线程安全的缺失：
解决这个问题最简单通常的方法是：使用mutex：
class Polynomial {
public:
using RootsType = std::vector<double>;
RootsType roots() const
{
std::lock_guard<std::mutex> g(m); //锁mutex
if(!rootsAreValid) {
...
rootsAreValid = true;
}
return rootVals;
} //解锁mutex
private:
mutable std::mutex m;
mutable bool rootsAreValid { false };
mutable RootsType rootsVals{};
};
std::mutex m 被声明为mutable，因为锁和解锁它是非const成员函数，在roots中（一个const成员函数），m会被视为一个const对象。
值得关注的是因为std::mutex既不能被拷贝也不能被移动，像Polynomial对象中添加m一个次要的影响是Polynomial失去类被拷贝和移动的能力。
有些情况中，用mutex是小题大做了。例如，如果你做的就是统计一个成员函数被调用了多少次，一个std::atomic counter（其他线程保证一旦它出现，会不可分割的调用它的操作）常常是一个更实惠的方法。（它到底是不是更实惠取决于你运行的硬件和标准库中mutexes的实现）。这是你应该如何使用std::atomic来统计调用次数:
class Point {
public:
...
double distanceFromOrigin() const noexcept
{
++callCount;
return std::hypot(x,y);
}
private:
mutable std::atomic<unsigned> callCount{ 0 };
double x,y;
};
像std::mutexes,std::atomics是不可拷贝和不可移动的，所以Point中callCount的存在意味着Point也是不可拷贝和移动的。
但是std::atomic变量上的操作经常要比mutex的获取和释放要实惠，你也许会被诱惑着太倾向于使用std::atomics。例如，一个类中存储一个计算消耗很大的int型值，你也许会尝试着使用一对std::atomic变量而不是一个mutex:
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> cacheValue;
};
这将会有用，但是有时候它将会比它本应该工作的更艰难。想象一下：
一个线程调用Widget::magicValue,看到cacheValid是false，执行了两个昂贵的计算操作，将他们的和赋值给cachedValue。
在这个时候，第二个线程调用Widget::magicValue，也看到cacheValid是false，并且因此进行了第一个线程刚结束的两个昂贵的计算操作。（这第二个线程事实上可能是几个）
要解决这个问题，你也许想着交换cachedValue的赋值操作和cacheValid的赋值操作，但是你很快认识到（1）多线程可能仍然会计算val1和val2（在cacheValid被设置为true前），thus
defeating the point of the exercis，并且（2）事实上它会让事情变得更糟。考虑一下：
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函数并且执行到cacheValue被设置为true的地方。
在这个时候，第二个线程调用Widget::magicValue并且检查cacheValid。看到它是true，线程返回了cachedValue，尽管第一个线程还没有对它进行赋值。返回值将会是不正确的。
这里有一个教训：对于单个变量或是内存需要同步，使用std::atomic是合适的，但是一旦你使用两个或者更多的变量或是内存需要同步（作为一个集合），你应该使用mutex。对于Widget::magicValue，它应该看起来像这样：
class Widget {
public:
...
int magicValue() const
{
std::lock_guard<std::mutex> guard(m);
if(cacheValid) return cacheValue;
else {
auto val1 = expensiveComputation1();
auto val2 = expensiveComputation2();
cachedValue = val1 + val2;
cacheValid = true;
return cacheValue;
}
}
...
private:
mutable std::mutex m;
mutable int cachedValue;
mutable bool cacheValid { false };
};
现在，这个Item基于假设多个线程同时执行一个对象上的一个const成员函数。如果你正在写一个const成员函数，它不在这种情况下------不会超过一个线程在一个对象上执行该成员函数-----函数的线程安全不是那么重要。例如，为单线程使用而设计的成员函数是不是线程安全的是不重要的。在这些例子中，你可以避免mutex和std::atomics相关的开销以及包含它们的类不可拷贝和不可移动的影响。然而，这些线程自由的情形越来越少见，并且它们很可能会变得十分稀有。安全的做法是const成员函数对于同步执行应该是满足的，这就是为什么你应该确保你的const成员函数应该是线程安全的。
 
Things to Remember
 
1.让const成员函数线程安全，除非你确信他们永远不会被用在同步情形下。
2.std::atomic变量的使用也许会提供比mutex更好的表现，但是它仅适合单个变量或者内存位置的控制。