[C++11 并发编程] 09 - 在初始化阶段保护共享数据

除了mutex，还有一些其它的方法在特定的场景下对共享数据进行保护，首先，我们来看看如何在初始化阶段保护数据。

有些时候，只需要在初始化阶段对共享数据进行保护，这样的数据可能在创建好之后是只读的，这样就没有同步问题。也可能在操作数据时，已经有了必要的保护。这样如何还是使用mutex来保护初始化过程，就没有太大必要，也比较影响性能。C++标准提供了一个纯粹用于在初始化阶段保护共享数据的机制。

假设有一个共享资源，加载它的代价很大，常见的做法是在真正要使用这块数据时，才构造它（Lazy initialization）。在单线程代码中，如下的实现是很常见的，需要使用特定资源的函数首先检查数据是否已经初始化好，如果没有，在使用数据之前首先对数据进行构造。

std::shared_ptr<some_resource> resource_ptr;
void foo()
{
    if(!resource_ptr)
    {
        // 在多线程环境下，初始化操作需要被保护
        resource_ptr.reset(new some_resource);
    }
    resource_ptr->do_something();
}

多线程情况下，使用mutex来保护初始化过程的代码如下：

#include <memory>
#include <mutex>

struct some_resource
{
    void do_something()
    {}
    
};


std::shared_ptr<some_resource> resource_ptr;
std::mutex resource_mutex;
void foo()
{
    // 所有调用foo()的线程在锁定mutex时都被串行化而降低了程序执行的效率
    std::unique_lock<std::mutex> lk(resource_mutex);
    if(!resource_ptr)
    {
        // 实际上，只有初始化代码才需要被保护
        resource_ptr.reset(new some_resource);
    }
    lk.unlock();
    resource_ptr->do_something();
}

int main()
{
    foo();
}

如上的实现方法会降低程序执行的效率，因为即使共享数据已经初始化好，每次调用foo()函数，还是回去锁定mutex，所有调用这个函数的线程，都会被不必要的串行化起来。很多人都尝试使用一种更“好”一点的做法来解决这个问题，包括声名狼藉的Double-Checked Locking模式。第一次访问指针时，不用获取锁，只有当指针为空时，才执行加锁操作，加锁以后再次检查指针是否为空。因为其它线程可能在我们第一次检查指针后到锁定mutex之前已经初始化了数据。

void undefined_behaviour_with_double_checked_locking()
{
    // 读操作和写操作没有同步
    if(!resource_ptr)
    {
        std::lock_guard<std::mutex> lk(resource_mutex);
	      if (!resource_ptr)
                   {
            resource_ptr.reset(new some_resource);
        }
    }
    // 可能导致do_something产生不正确的结果
    resource_ptr->do_something();
}

这种类型的race condition称为“data race”，其结果是未定义的。C++标准提供了std::once_flag和std::call_once来解决这个问题。

每个线程都通过调用std::call_once来安全的初始化资源，在数据已经被初始化的情况下，std::call_once的开销远远小于锁定mutex以及对指针进行检查。实例如下：

#include <mutex>

struct connection_info
{};

struct data_packet
{};

struct connection_handle
{
    void send_data(data_packet const&)
    {}
    data_packet receive_data()
    {
        return data_packet();
    }
};

struct remote_connection_manager
{
    connection_handle open(connection_info const&)
    {
        return connection_handle();
    }
} connection_manager;


class X
{
private:
    connection_info connection_details;
    connection_handle connection;
    std::once_flag connection_init_flag;

    // 用于初始化资源的函数
    void open_connection()
    {
        connection=connection_manager.open(connection_details);
    }
public:
    X(connection_info const& connection_details_):
        connection_details(connection_details_)
    {}
    // 资源可以在第一次调用send_data时被初始化
    void send_data(data_packet const& data)
    {
        // 将成员函数指针和类的实例传递给std::call_once
        std::call_once(connection_init_flag,&X::open_connection,this);
        connection.send_data(data);
    }
    // 也可以在第一次调用receive_data时被初始化
    data_packet receive_data()
    {
        // 将成员函数指针和类的实例传递给std::call_once
        std::call_once(connection_init_flag,&X::open_connection,this);
        return connection.receive_data();
    }
};

int main()
{}

另一种方法是使用静态局部变量。在C++11中，静态局部变量的初始化只会发生在一个确定的线程中，其它线程会等待该变量初始化完成才能继续执行，这样race condition就从一个麻烦的问题转换为选择一个线程来进行初始化操作。在只需要一个单独的全局变量时，可以使用这种方法代替std::call_once：

class my_class;
my_class& get_my_class_instance()
{
    // 初始化保证了线程间的安全性
    static my_class instance;
    return instance;
}

多个线程可以安全的调用get_my_class_instance()而无需担心初始化时的race condition。
这一节，针对在初始化阶段保护数据，下一节我们看看如何保护一个很少被就该的数据结构。在大多数情况下，这块数据都是只读的，只有在极少的情况下才会修改这块数据。