Generic<Programming>：volatile——编写多线程程序的好帮手

最新推荐文章于 2018-10-30 11:34:33 发布

renwotao2009

最新推荐文章于 2018-10-30 11:34:33 发布

阅读量1k

点赞数

分类专栏： C/C++-多线程文章标签：多线程编译器 buffer class vector

C/C++-多线程专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Andrei Alexandrescu
ye_feng 译

并不是我故意想弄糟你的心情，但是在这期专栏里，我们将讨论多线程编程这一话题。正如上一期 Generic<Programming>里所说的，编写异常安全（exception-safe）的程序是非常困难的，但是和编写多线程程序比起来，那简直就是儿戏。

多线程的程序是出了名的难编写、难验证、难调试、难维护，这通常是件苦差事。不正确的多线程程序可能可以运行很多年也不出一点错，直到满足某些临界的条件时，才出现意想不到的奇怪错误。

不用说，编写多线程程序的程序员需要使用可能得到的所有帮助。这期专栏将专注于讨论竞争条件（race conditions ）——这通常是多线程程序中各种麻烦的根源——深入了解它并提供一些工具来防止竞争。令人惊异的是，我们将让编译器尽其所能来帮助你做这些事。

仅仅一个不起眼的关键字

尽管 C 和 C++标准对于线程都明显的 “保持沉默”，但它们以 volatile关键字的形式，确实为多线程保留了一点特权。

就象大家更熟悉的 const一样，volatile 是一个类型修饰符（type modifier ）。它是被设计用来修饰被不同线程访问和修改的变量。如果没有 volatile，基本上会导致这样的结果：要么无法编写多线程程序，要么编译器失去大量优化的机会。下面我们来一个个说明。

考虑下面的代码： 

    class Gadget 

    { 

    public: 

        void Wait() 

        { 
            while (!flag_) 

           { 

                Sleep(1000); // sleeps for 1000 milliseconds 

           } 

        } 
        void Wakeup() 

        {             
              flag_ = true; 
        } 

        ... 

    private: 

        bool flag_; 

    };

上面代码中Gadget::Wait的目的是每过一秒钟去检查一下flag_成员变量，当 flag_ 被另一个线程设为 true时，该函数才会返回。至少这是程序作者的意图，然而，这个 Wait 函数是错误的。

假设编译器发现 Sleep(1000)是调用一个外部的库函数，它不会改变成员变量 flag_，那么编译器就可以断定它可以把 flag_缓存在寄存器中，以后可以访问该寄存器来代替访问较慢的主板上的内存。这对于单线程代码来说是一个很好的优化，但是在现在这种情况下，它破坏了程序的正确性：当你调用了某个 Gadget 的 Wait 函数后，即使另一个线程调用了Wakeup，Wait还是会一直循环下去。这是因为 flag_的改变没有反映到缓存它的寄存器中去。编译器的优化未免有点太……乐观了。

在大多数情况下，把变量缓存在寄存器中是一个非常有价值的优化方法，如果不用的话很可惜。C和 C++给你提供了显式禁用这种缓存优化的机会。如果你声明变量是使用了volatile 修饰符，编译器就不会把这个变量缓存在寄存器里——每次访问都将去存取变量在内存中的实际位置。这样你要对 Gadget 的Wait/Wakeup 做的修改就是给 flag_加上正确的修饰：

    class Gadget 

    { 
    public: 

        ... as above ... 

    private: 

        volatile bool flag_; 

    };

大多数关于 volatile 的原理和用法的解释就到此为止，并且建议你用 volatile修饰在多个线程中使用的原生类型变量。然而，你可以用 volatile 做更多的事，因为它是神奇的C++类型系统的一部分。

把 volatile用于自定义类型

volatile 修饰不仅可以用于原生类型，也可以用于自定义类型。这时候，volatile修饰方式类似于 const （你也可以对一个类型同时使用 const和 volatile）。

与 const不同，volatile 的作用对于原生类型和自定义类型是有区别的。就是说，原生类型有 volatile修饰时，仍然支持它们的各种操作（加、乘、赋值等等），然而对于 class来说，就不是这样。举例来说，你可以把一个非 volatile 的 int 的值赋给一个volatile的 int，但是你不能把一个非 volatile 的对象赋给一个volatile对象。

让我们举个例子来说明自定义类型的 volatile是怎么工作的。

    class Gadget 

    { 

    public: 

        void Foo() volatile; 

        void Bar(); 
        ... 

    private: 

        String name_; 

        int state_; 

    }; 
    ... 

    Gadget regularGadget; 

    volatile Gadget volatileGadget; 

    如果你认为 volatiled对于对象来说没有什么作用的话，那你可要大吃一惊了。 

    volatileGadget.Foo(); // ok, volatile fun called for 

                             // volatile object 

    regularGadget.Foo();  // ok, volatile fun called for 

                             // non-volatile object 
    volatileGadget.Bar(); // error! Non-volatile function called for 

                             // volatile object! 

    从没有 volatile修饰的类型到相应的 volatile类型的转换是很平常的。但是，就想 

const一样，你不能反过来把 volatile类型转换为非volatile类型。你必须用类型转换 
运算符： 

    Gadget& ref = const_cast<Gadget&>(volatileGadget); 

    ref.Bar(); // ok

一个有 volatile 修饰的类只允许访问其接口的一个子集，这个子集由类的实现者来控制。用户只有用 const_cast才可以访问这个类型的全部接口。而且，象 const 一样，类的 volatile 属性会传递给它的成员（例如， volatileGadget.name_ 和volatileGadget.state_也是 volatile变量）。

volatile，临界区和竞争条件

多线程程序中最简单也是最常用的同步机制要算是mutex （互斥对象）了。一个mutex 只提供两个基本操作：Acquire和 Release。一旦某个线程调用了 Acquire，其他线程再调用 Acquire 时就会被阻塞。当这个线程调用 Release后，刚才阻塞在Acquire里的线程中，会有一个且仅有一个被唤醒。换句话说，对于一个给定的 mutex ，只有一个线程可以在Acquire和 Release调用之间获取处理器时间。在 Acquire 和 Release调用之间执行的代码叫做临界区（critical section。Windows 的用语可能会引起一点混乱，因为Windows 把 mutex本身叫做临界区，而 Windows 的mutex 实际上指进程间的 mutex 。如果把它们分别叫作线程mutex 和进程 mutex 可能会好些。）。

Mutex 是用来避免数据出现竞争条件。根据定义，所谓竞争条件就是这样一种情况：多个线程对数据产生的作用要依赖于线程的调度顺序的。当两个线程竞相访问同一数据时，就会发生竞争条件。因为一个线程可以在任意一个时刻打断其他线程，数据可能会被破坏或者被错误地解释。因此，对数据的修改操作，以及有些情况下的访问操作，必须用临界区保护起来。在面向对象的编程中，这通常意味着你在一个类的成员变量中保存一个 mutex，然后在你访问这个类的状态时使用这个 mutex 。

多线程编程高手看了上面两个段落，可能已经在打哈欠了，但是它们的目的只是提供一个准备练习，我们现在要和 volatile联系起来了。我们将把 C++的类型和线程的语义作一个对比。

在一个临界区以外，任意线程会在任何时间打断别的线程；这是不受控制的，所以被多个线程访问的变量容易被改得面目全非。这和 volatile 的初衷是一致的——防止编译器无意地缓存这样的变量。

在由一个 mutex 限定的临界区里，只有一个线程可以进入。因此，在临界区中执行的代码有和单线程程序有相同的语义。被控制的变量不会再被乱改一气——你可以去掉volatile修饰。

简而言之，线程间共享的数据在临界区之外会被乱改，而在临界区之内则不会。

你通过对一个 mutex 加锁来进入一个临界区，然后你用 const_cast 去掉某个类型的volatile 修饰，如果我们能成功地把这两个操作放到一起，那么我们就在 C++类型系统和应用程序的线程语义建立起联系。这样我们可以让编译器来帮我们检测竞争条件。

LockingPtr

我们需要有一个工具来做 mutex的获取和 const_cast 两个操作。让我们来设计一个LockingPtr类，你需要用一个 volatile 的对象obj和一个 mutex 对象 mtx来初始化它。在 LockingPtr 对象的生命期中，它会保证 mtx 处于被获取状态，而且也提供对去掉volatile修饰的 obj 的访问。对 obj 的访问类似于smart pointer ，是通过 operator->和operator*来进行的。const_cast 是在 LockingPtr 内部进行。这个转化在语义上是正确的，因为LockingPtr在其生存期中始终拥有 mutex 。

首先，我们来定义和 LockingPtr一起工作的Mutex类的框架：

    class Mutex 

    { 
    public: 

        void Acquire(); 

        void Release(); 

        ... 

    };

为了使用 LockingPtr，你需要用操作系统提供的数据结构和底层函数来实现 Mutex。

LockingPtr 是一个模板，用被控制变量的类型作为模板参数。例如，如果你希望控制一个 Widget，你就要这样写 LockingPtr <Widget>。

LockingPtr 的定义很简单，它只是实现了一个单纯的 smart pointer 。它关注的焦点只是在于把 const_cast和临界区操作放在一起。

template <typename T> 
    class LockingPtr { 

    public: 

       // Constructors/destructors 

       LockingPtr(volatile T& obj, Mutex& mtx) 

           : pObj_(const_cast<T*>(&obj)), 
           pMtx_(&mtx) 

       {    mtx.Lock();     } 

       ~LockingPtr() 

       {    pMtx_->Unlock();      } 

       // Pointer behavior 
       T& operator*() 

       {    return *pObj_;      } 

       T* operator->() 

       {   return pObj_;    } 

    private: 
       T* pObj_; 

       Mutex* pMtx_; 

       LockingPtr(const LockingPtr&); 

       LockingPtr& operator=(const LockingPtr&); 

    };

尽管很简单，LockingPtr 对于编写正确的多线程代码非常有用。你应该把线程间共享的对象声明为 volatile，但是永远不要对它们使用 const_cast——你应该始终是用LockingPtr 的自动对象（automatic objects）。让我们举例来说明。

比如说你有两个线程需要共享一个vector<char>对象：

    class SyncBuf { 
    public: 

        void Thread1(); 

        void Thread2(); 

    private: 

        typedef vector<char> BufT; 
        volatile BufT buffer_; 

        Mutex mtx_; // controls access to buffer_ 

    };

在一个线程的函数里，你只需要简单地使用一个 LockingPtr<BufT>对象来获取对buffer_成员变量的受控访问：

 void SyncBuf::Thread1() { 

        LockingPtr<BufT> lpBuf(buffer_, mtx_); 

        BufT::iterator i = lpBuf->begin(); 
        for (; i != lpBuf->end(); ++i) { 

            ... use *i ... 

        } 

    }

这样的代码很容易编写，也很容易理解——每当你需要使用 buffer_时，你必须创建一个 LockingPtr<BufT>来指向它。当你这样做了以后，你就可以访问 vector 的全部接口。

这个方法的好处是，如果你犯了错误，编译器会指出它：

void SyncBuf::Thread2() { 

        // Error! Cannot access 'begin' for a volatile object 

        BufT::iterator i = buffer_.begin(); 

        // Error! Cannot access 'end' for a volatile object 

        for (; i != lpBuf->end(); ++i) { 
           ... use *i ... 

        } 

    }

你不能访问 buffer_的任何函数，除非你进行了 const_cast 或者用 LockingPtr。这两者的区别是 LockingPtr 提供了一个有规则的方法来对一个 volatile 变量进行const_cast。
LockingPtr 有非常好的表达力。如果你只需要调用一个函数，你可以创建一个无名的临时LockingPtr对象，然后直接使用它：

unsigned int SyncBuf::Size() { 

        return LockingPtr<BufT>(buffer_, mtx_)->size(); 
    }

回到原生类型
我们已经看到了 volatile 对于保护对象免于不受控的访问是多么出色，并且看到了LockingPtr 是怎么提供了一个简单有效的办法来编写线程安全的代码。现在让我们回到原生类型，volatile对它们的作用方式是不同的。

让我们来考虑一个多个线程共享一个 int变量的例子。

class Counter 

    { 

    public: 

        ... 
        void Increment() { ++ctr_; } 

        void Decrement() { ——ctr_; } 

    private: 

        int ctr_; 

    };

如果 Increment和 Decrement 是在不同的线程里被调用的，上面的代码片断里就有bug 。首先，ctr_必须是 volatile 的。其次，即使是一个看上去是原子的操作，比如++ctr_，实际上也分为三个阶段。内存本身是没有运算功能的，当对一个变量进行增量操作时，处理器会：

l 把变量读入寄存器

l 对寄存器里的值加 1

l 把结果写回内存

这个三步操作称为 RMW （Read-Modify-Write）。在一个 RMW 操作的 Modify 阶段，大多数处理器都会释放内存总线，以使其他处理器能够访问内存。

如果在这个时候另一个处理器对同一个变量也进行 RMW 操作，我们就遇到了一个竞争条件：第二次写入会覆盖掉第一次的值。

为了防止这样的事发生，你又要用到 LockingPtr：

class Counter 
    { 

    public: 

        ... 

        void Increment() { ++*LockingPtr<int>(ctr_, mtx_); } 

        void Decrement() { —*LockingPtr<int>(ctr_, mtx_); } 
    private: 

        volatile int ctr_; 

        Mutex mtx_; 

    };

现在这段代码正确了，但是和 SyncBuf相比，这段代码的质量要差一些。为什么？因为对于 Counter，编译器不会在你错误地直接访问 ctr_ （没有对它加锁）时产生警告。虽然ctr_是 volatile 的，但是编译器还是可以编译++ctr_，尽管产生的代码绝对是不正确的。编译器不再是你的盟友了，你只有自己留意竞争条件。

那么你该怎么做呢？很简单，你可以用一个高层的结构来包装原生类型的数据，然后对那个结构使用 volatile。这有点自相矛盾，直接用 volatile修饰原生类型是一个不好的用法，尽管这是 volatile最初期望的用法！

volatile 成员函数

到现在为止，我们讨论了具有 volatile 数据成员的类；现在让我们来考虑设计这样的类，它会作为更大的对象的一部分并且在线程间共享。这里，volatile 的成员函数可以帮很大的忙。

在设计类的时候，你只对那些线程安全的成员函数加 volatile 修饰。你必须假定外面的代码会在任何地方任何时间调用volatile成员函数。不要忘记：volatile相当于自由的多线程代码，并且没有临界区；非 volatile相当于单线程的环境或者在临界区内。

比如说，你定义了一个 Widget 类，它用两个方法实现了同一个操作——一个线程安全的方法和一个快速的不受保护的方法。

class Widget 

    { 
    public: 

        void Operation() volatile; 

        void Operation(); 

        ... 

    private: 
        Mutex mtx_; 

    };

注意这里的重载（overloading ）用法。现在 Widget 的用户可以用一致的语法调用Operation，对于 volatile对象可以得到线程安全性，对于普通对象可以得到速度。用户必须注意把共享的Widget对象定义为 volatile。

在实现 volatile成员函数时，第一个操作通常是用 LockingPtr对 this进行加锁，然后其余工作可以交给非 volatile 的同名函数做：

void Widget::Operation() volatile 

    { 

        LockingPtr<Widget> lpThis(*this, mtx_); 
        lpThis->Operation(); // invokes the non-volatile function 

    }

小结

在编写对线程程序的时候，使用 volatile将对你十分有益。你必须坚持下面的规则：

l 把所有共享对象声明为 volatile

l 不要对原生类型直接使用 volatile

l 定义共享类时，用 volatile成员函数来表示它的线程安全性。

如果你这么做了，而且用了简单的泛型组件 LockingPtr，你就可以写出线程安全的代码，并且大大减少对竞争条件的担心，因为编译器会替你操心，并且勤勤恳恳地为你指出哪里错了。

在我参与的几个项目中，使用 volatile和 LockingPtr产生了很大效果。代码十分整洁，也容易理解。我记得遇到过一些死锁的情况，但是相对于竞争条件，我宁愿对付死锁的情况，因为它们调试起来容易多了。那些项目实际上根本没有碰到过有关竞争条件的问题。

致谢

非常感谢 James Kanze 和 Sorin Jianu 提供了很有洞察力的意见。

后续话题：

滥用volatile 的实质？

在专栏 “Generic<Programming>: volatile — Multithreaded Programmer's Best Friend”发表以后，我收到很多反馈意见。就像是注定的一样，大部分称赞都是私人信件，而抱怨都发到USENET 新闻组 comp.lang.c++.moderated 和 comp.programming.threads 里去了。随后引起了很长很激烈的讨论，如果你对这个主题有兴趣，你可以去看看这个讨论，它的标题是“volatile, was: memory visibility between threads. ”。

我知道我从这个讨论中学到了很多东西。比如说，文章开头的 Widget 的例子不太切题。长话短说，在很多系统（比如POSIX 兼容的系统）中，volatile修饰是不需要的，而在另一些系统中，即使加了volatile也没有用，程序还是不正确。

关于volatile correctness ，最重要的一个问题是它依赖于类似 POSIX 的mutex，如果在多处理器系统上，光靠mutex 就不够了——你必须用 memory barriers。

另一个更理性的问题是：严格来说通过类型转换把变量的 volatile 属性去掉是不合法的，即使volatile属性是你自己为了 volatile correctness 而加上去的。正如Anthony Williams指出的，可以想象一个系统可能把 volatile数据放在一个不同于非 volatile数据的存储区中，在这种情况下，进行地址变换会有不确定的行为。

另一个批评是volatile correctness 虽然可以在一个较低层次上解决竞争条件，但是不能正确的检测出高层的、逻辑的竞争条件。例如，你有一个 mt_vector 模版类，用来模拟std::vector，成员函数经过正确的线程同步修正。考虑这段代码：

    volatile mt_vector<int> vec; 

    … 
    if (!vec.empty()) { 

        vec.pop_back(); 

    }

这段代码的目的是删除 vector里的最后一个元素，如果它存在的话。在单线程环境里，他工作地很好。然而如果你把它用在多线程程序里，这段代码还是有可能抛出异常，尽管empty 和 pop_back 都有正确的线程同步行为。虽然底层的数据（vec）的一致性有保证，但是高层操作的结果还是不确定的。

无论如何，经过辩论之后，我还是保持我的建议，在有类 POSIX 的mutex 的系统上，volatile correctness 还是检测竞争条件的一个有价值的工具。但是如果你在一个支持内存访问重新排序的多处理器系统上，你首先需要仔细阅读你的编译器的文档。你知道你在做什么。

最后，Kenneth Chiu 提到了一篇非常有趣的文章 http://theory.stanford.edu/~freunds/race.ps ，猜猜题目是什么，“Type-Based Race Detection for Java”。这篇文章讲了怎么对 Java 的类型系统作一点小小的补充，从而让编译器和程序员一起在编译时检测竞争条件。

Eppur si muove.

【这是伽利略在被迫放弃他一直信仰的哥白尼的地动说时所说过的一句辩解的话，意思是“它（地球）仍在运动”。】