3.2使用互斥量保护共享数据
C++通过实例化std::mutex创建互斥量,通过调用成员函数lock()/unlock()来进行加解锁。不过不推荐直接调用成员函数,因为必须记住在每一个函数的出口都要调用unlock(),包括异常。C++标准库提供了一个RAII的模板类std::lock_guard,其会在构造函数的提供已加锁的互斥量,并在析构函数的时候进行解锁,从而保证一个已锁的互斥量总会被正确的解锁。
如下是lock_guard实例:
#include <iostream>
#include <list>
#include <mutex>
#include <algorithm>
#include <thread>
std::list<int> some_list; //1
std::mutex some_mutex; //2
void add_to_list(int new_value)
{
std::lock_guard<std::mutex> guard(some_mutex); //3
some_list.push_back(new_value);
}
bool list_contains(int value_to_find)
{
std::lock_guard<std::mutex> guard(some_mutex); //4
return
std::find(some_list.begin(),some_list.end(),value_to_find)
!= some_list.end();
}
int main()
{
std::thread threads[5];
for(int i = 0; i < 5; ++i)
{
threads[i] = std::thread(add_to_list,i);
}
for(auto& it:threads)
{
it.join();
}
for(auto& it :some_list)
{
std::cout << it << std::endl;
}
}
3.2.2精心组织代码来保护共享数据
使用互斥量来保护数据,并不是仅仅在在每一个成员函数中都加入std::lock_guard对象那么简单,并且还要检查迷失指针和引用:只要没有成员函数通过返回值或输出参数的形式向调用者指向受保护的数据的指针或引用,数据就是安全的。在确保成员函数不会传出指针或者引用的同时,检查成员函数是否通过指针和引用的方式来调用也是很重要的。函数可能没在互斥量保护区域内,存储的指针或引用,这样很危险,更危险的是:将保护数据作为一个运行时参数,如同下面那样:
无意传递了保护数据的引用:
class some_data
{
int a;
std::string b;
public:
void do_something();
};
class data_wrapper
{
private:
some_data data;
std::mutex m;
public:
template<typename Function>
void process_data(Function func)
{
std::lock_guard<std::mutex> l(m);
func(data); //1 传递"保护"数据给用户函数
}
};
some_data* unprotected;
void malicious_function(some_data& protected_data)
{
unprotected = &protected_data;
}
data_wrapper x;
void foo()
{
x.process_data(malicious_function); //传递一个恶意函数
unprotected->do_something(); //在无保护的情况下访问保护数据
}
例子中process_data看起来没有任何问题,std::lock_guard对数据起到了很好的保护,但调用用户提供的函数func(1),就以为着foo能够绕过保护机制将函数malicious_function传递进去(2),在没有互斥的量的情况下调用do_something()。
3.2.3发现接口内在的条件竞争
因为使用互斥量或其他机制来保护共享数据,还要担心条件竞争:对于双向链表操作而言,为了确保让线程安全的删除一个节点,需要确保防止对三个节点(待删除的节点,及其前后相邻的节点)的并发访问。
尽管链表的个别操作时安全的,但不意味着你走出困境:即使在一个很简单的接口中,依旧可能遇到条件竞争。如下:构建一个类似std::stack的栈,除了构造函数和swap()外,需要对std::stack提供五个操作:push,pop,top,empty,size操作。即使修改了top,使其返回一个拷贝而非引用,对内部数据使用互斥量进行保护,条件竞争依然存在。这个问题不仅在于基于互斥量实现的接口中,在无锁实现的接口中,条件竞争依然存在。这是接口的问题,与其实现方式无关。
template<typename T,typename Container = std::deque<T> >
class stack
{
explicit stack(const Container&);
explicit stack(Container&& = Container());
template<class Alloc> explicit stack(const Alloc&);
template<class Alloc> explicit stack(const Container&,const Alloc&);
template<class Alloc> explicit stack(Container&&,const Alloc&);
template<class Alloc> explicit stack(stack&&,const Alloc&);
bool empty() const;
size_t size() const;
T& top();
T const& top() const;
void push(T const&);
void push(T&&);
void pop();
void swap(stack&&);
};
虽然empty和size可能被调用并返回正确的结果,但结果是不可靠的:当他们返回后,其他线程就可以自由的访问栈,可能push多个新元素,也可能pop一些栈中的元素,这样的话之前的empty和size就有问题了。
当栈实例是非共享的,如果栈非空,使用empty检查在调用top访问栈顶的元素是安全的:
stack<int> s;
if(!s.empty()) //1
{
int const value = s.top(); //2
s.pop(); //3
do_something(value);
}
对于共享的栈而言,这样调用顺序就不再安全,即使使用互斥量来保护,依然不能阻止条件竞争,这是接口固有问题。例如在调用empty和top之间,可能有来自另一个线程调用pop删除了最后一个元素。
如下是线程安全的堆栈类定义:重载了pop,使用局部引用存储弹出的值,并返回一个std::shared_ptr对象。
#include <exception>
#include <memory> //for std::shared_ptr
struct empty_stack: std::exception
{
const char* what() const throw();
};
template<typename T>
class threadsafe_stack
{
public:
threadsafe_stack();
threadsafe_stack(const threadsafe_stack&);
threadsafe_stack& operator=(const threadsafe_stack&) = delete;
//1 赋值操作被删除
void push(T new_value);
std::shared_ptr<T> pop();
void pop(T& value);
bool empty() const;
};
删减接口可以获得最大程度的安全,甚至限制对栈的一些操作。栈不能直接赋值的(1),并且这里没有swap函数。栈可以拷贝,当栈为空的时候,pop函数会抛出异常。所以在empty函数被调用后,其他部件依然能正常工作。使用了std::shared_ptr避免内存管理问题,并避免多次使用new和delete。现在只剩下三个:push,pop和empty。
如下封装了std::stack<>的线程安全的栈,将top和pop合成一个函数:
#include <exception>
#include <memory>
#include <mutex>
#include <stack>
struct empty_stack: std::exception
{
const char* what() const throw();
};
template <typename T>
class threadsafe_stack
{
private:
std::stack<T> data;
mutable std::mutex m;
public:
threadsafe_stack()
:data(std::stack<T>()){}
threadsafe_stack(const threadsafe_stack& other)
{
std::lock_guard<std::mutex> lock(other.m);
data = other.data; //1 在构造函数中执行拷贝
}
threadsafe_stack& operator=(const threadsafe_stack&) = delete;
void push(T new_value)
{
std::lock_guard<std::mutex> lock(m);
data.push(new_value);
}
std::shared_ptr<T> pop()
{
std::lock_guard<std::mutex> lock(m);
if(data.empty()) throw empty_stack(); //在pop之前检查栈是否为空
std::shared_ptr<T> const res(std::make_shared<T>(data.top()));//在修改堆栈之前,分配并返回
data.pop();
return res;
}
void pop(T& value)
{
std::lock_guard<std::mutex> lock(m);
if(data.empty()) throw empty_stack();
value = data.top();
data.pop();
}
bool empty() const
{
std::lock_guard<std::mutex> lock(m);
return data.empty();
}
};
3.2.4死锁:问题描述及解决方案
对于线程对于锁的竞争:一对线程需要对它们所有的互斥量做一些操作,其中每一个线程都有互斥量,切等待另一个解锁。这样没有线程能工作,因为他们都在等待对方释放互斥量。这种情况就是死锁,他最大的问题就是由两个及两个以上的互斥量来锁住一个操作。
避免死锁的一般建议:就是让两个互斥量总是以相同的顺序上锁,就永远不会死锁。仅限于不同的互斥量用于不同的地方。当多个互斥量保护同一个类的独立实例时:一个操作对同一个类两个不同的实例进行数据交换操作时,为了保证数据交换操作的正确性,就要避免并发修改数据。如果选择一个固定顺序上锁(例如,实例提供了第一个互斥量作为第一个参数,提供了第二个互斥量作为第二参数)可能会适得其反:在参数交换后,两个线程试图在相同的两个实例间进行数据交换,程序死锁了。
C++标准库提供解决的方法——std::lock,可以一次锁住多个(两个以上)的互斥量,并且没有副作用(死锁风险)。
如下代码就是怎么在一个简单的交换操作中使用std::lock:
//std::lock()需要包括<mutex>头文件
class some_big_object;
void swap(some_big_object& lhs,some_big_object& rhs);
class X
{
private:
some_big_object some_detail;
std::mutex m;
public:
X(some_big_object const& sd):some_detail(sd){}
friend void swap(X& lhs,X& rhs)
{
if(&lhs == &rhs)
return;
std::lock(lhs.m,rhs.m); //1
std::lock_guard<std::mutex> lock_a(lhs.m,std::adopt_lock); //2
std::lock_guard<std::mutex> lock_b(rhs.m,std::adopt_lock); //3
swap(lhs.some_detail,rhs.some_detail);
}
};
3.2.5避免死锁的进阶指导
为了避免死锁的指导意见:当获取锁机会来临,就不要拱手让人。以下是如何识别死锁,并消除其他线程等待方法:
- 避免嵌套锁。一个线程已获取一个锁时,别再去获取第二个。
- 避免在持有锁时调用用户提供的代码。
- 使用固定顺序获取锁。
- 使用锁的层次结构。
锁的层次在于提供对运行时约定是否被坚持检查。这个建议需要对你的应用层分层,并且识别在给定层上所有可上锁的互斥量。当代码试图对一个互斥量上锁,在该层锁已被低层持有时,上锁是不允许的。你可以在运行时对其进行检查,通过分配层数到每个互斥量,以及记录被每个线程上锁的互斥量。
下面的代码列表中将展示两个线程如何使用分层互斥:
hierarchical_mutex high_level_mutex(10000); //1
hierarchical_mutex low_level_mutex(5000); //2
int do_low_level_stuff();
int low_level_func()
{
std::lock_guard<hierarchical_mutex> lk(low_level_mutex); //3
return do_low_level_stuff();
}
void high_level_stuff(int some_param);
void high_level_func()
{
std::lock_guard<hierarchical_mutex> lk(high_level_mutex); //4
high_level_stuff(low_level_func); //5
}
void thread_a() //6
{
high_level_func();
}
hierarchical_mutex other_mutex(100); //7
void do_other_stuff();
void other_stuff()
{
high_level_func(); //8
do_other_stuff();
}
void thread_b()
{
std::lock_guard<hierarchical_mutex> lk(other_mutex); //10
other_stuff();
}
上述thread_a能正常运行:thread_调用时首先上高层次的锁10000,再上低层次的锁5000。thread_b可能会抛异常:因为thread_b第一个锁是低层次的100,再去上高层次的锁。
hierachical_mutex不是C++标准的一部分,它的实现函数有三个为了满足互斥操作:lock,unlock和trylock。try_lock功能当互斥量上的锁被一个线程持有,它将立刻返回false,而不是等待调用的线程。在std::lock的内部实现中,try_lock作为避免死锁算法的一部分。
class hierarchical_mutex
{
std::mutex internal_mutex;
unsigned long const hierarchi_value;
unsigned long previous_hierarchi_value;
static thread_local unsigned long this_thread_hierarchy_value; //1
void check_for_hierarchy_violation()
{
if(this_thread_hierarchy_value <= hierarchi_value) //2
{
throw std::logic_error("mutex hierarchi violated");
}
}
void undate_hierarchy_value()
{
previous_hierarchi_value = this_thread_hierarchy_value; //3
this_thread_hierarchy_value = hierarchi_value;
}
public:
explicit hierarchical_mutex(unsigned long value):
hierarchi_value(value),previous_hierarchi_value(0){}
void lock()
{
check_for_hierarchy_violation();
internal_mutex.lock(); //4
undate_hierarchy_value();//5
}
void unlock()
{
this_thread_hierarchy_value = previous_hierarchi_value; //6
internal_mutex.unlock();
}
bool try_lock()
{
check_for_hierarchy_violation();
if(!internal_mutex.try_lock()) //7
return false;
undate_hierarchy_value();
return true;
}
};
thread_local unsigned long
hierarchical_mutex::this_thread_hierarchy_value(ULONG_MAX);
3.2.6 std::unique_lock——灵活的锁
std::unique_lock使用更加自由的不变量,这样std::unique_lock实例不会总于互斥量的数据相关,使用起来要比std::lock_guard更加灵活。可以针对std::adopt_lock作为第二参数对互斥量进行管理;也可以将std::defer_lock表示互斥量应该保持解锁状态。
作为灵活度的牺牲,std::unique_lock比起std::lock_guard空间会大些,速度要慢些。
如下是使用std::unique_lock实现std::lock_guard同样的代码:
//std::lock()需要包括<mutex>头文件
class some_big_object;
void swap(some_big_object& lhs,some_big_object& rhs);
class X
{
private:
some_big_object some_detail;
std::mutex m;
public:
X(some_big_object const& sd):some_detail(sd){}
friend void swap(X& lhs,X& rhs)
{
if(&lhs == &rhs)
return;
std::unique_lock<std::mutex> lock_a(lhs.m,std::defer_lock); //1
std::unique_lock<std::mutex> lock_b(rhs.m,std::defer_lock); //1
std::lock(lock_a,lock_b); //在这里上锁
swap(lhs.some_detail,rhs.some_detail);
}
};
3.2.7 不同域中互斥量所有权的传递
std::unique_lock实例没有与自身相关的互斥量,一个互斥量的所有权可以通过移动操作,在不同的实例中进行传递:当函数返回一个实例的时候,自动转移;另一些情况需要显示调用std::move来执行操作:需要依赖源值是否是左值——一个实例的值或是引用,或是右值——一个临时的类型。当源值是一个右值的时候,就要显示移动成左值。std::unique_lock是可移动,但不可赋值的。
一种使用可能允许一个函数取锁住一个互斥量,并将所有权移到调用者身上,所以调用者可以在这个锁保护的范围内执行额外的操作:
std::unique_lock<std::mutex> get_lock()
{
extern std::mutex some_mutex;
std::unique_lock<std::mutex> lk(some_mutex);
prepare_data();
return lk; //1
}
void process_data()
{
std::unique_lock<std::mutex> lk(get_lock()); //2
do_something();
}
3.2.8 锁的粒度
锁的粒度表示:通过一个锁保护着的数据量的大小。一个细粒度锁能够保护较小的数据量,一个粗粒度的锁能够保护较多的数据量。为了保护对应的数据,保证锁有能力保护这些数据很重要。