互斥

互斥是多线程系统中用于控制访问的一个原对象(primitive object)。下面的例子给出了它最基本的用法:

std::mutex  m;
int sh; //共享数据
// …
m.lock();
// 对共享数据进行操作:
sh += 1;
m.unlock();

在任何时刻,最多只能有一个线程执行到lock()和unlock()之间的区域(通常称为临界区)。当第一个线程正在临界区执行时,后续执行到m.lock()的线程将会被阻塞直到第一个进程执行到m.unlock()。这个过程比较简单,但是如何正确使用互斥并不简单。错误地使用互斥将会导致一系列严重后果。大家可以设想以下情形所导致的后果:一个线程只进行了lock()而没有执行相应unlock(); 一个线程对同一个mutex对象执行了两次lock()操作;一个线程在等待unlock()操作时被阻塞了很久;一个线程需要对两个mutex对象执行lock()操作后才能执行后续任务。可以在很多书(译者注:通常操作系统相关书籍中会讲到)中找到这些问题的答案。在这里(包括Locks section一节)所给出的都是一些入门级别的。

除了lock(),mutex还提供了try_lock()操作。线程可以借助该操作来尝试进入临界区,这样一来该线程不会在失败的情况下被阻塞。下面例子给出了try_lock()的用法:

std::mutex m;
int sh; //共享数据
// …
if (m.try_lock()) {
    //操作共享数据
    sh += 1;
    m.unlock();
}
else {
    //可能在试图进入临界区失败后执行其它代码
}

recursive_mutex是一种能够被同一线程连续锁定多次的mutex。下面是recursive_mutex的一个实例:

std::recursive_mutex m;
 int sh; //共享数据
 //..
 void f(int i)
 {
     //…
     m.lock();
     //对共享数据进行操作
     sh += 1;
     if (–i>0) f(i);  //注意:这里对f(i)进行了递归调用,
     //将导致在m.unlock()之前多次执行m.lock()
     m.unlock();
     //…
 }

对于这点,我曾经夸耀过并且用f()调用它自身。一般地,代码会更加微妙。这是因为代码中经常会有间接递归调用。比如f()调用g(),而g()又调用了h(),最后h()又调用了f(),这样就形成了一个间接递归。

如果我想在未来的10秒内进入到一个mutex所划定的临界区,该如果实现? timed_mutex类可以解决这个问题。事实上,关于它的使用可以被看做是关联了时间限制的try_lock()的一个特例。

std::timed_mutex m;
int sh; //共享数据
//…
if ( m.try_lock_for(std::chrono::seconds(10))) {
//对共享数据进行操作
sh += 1;
m.unlock();
}
else {
    //进入临界区失败,在此执行其它代码
}

try_lock_for()的参数是一个用相对时间表示的duration。如果你不想这么做而是想等到一个固定的时间点:一个time_point,你可以使用try_lock_until():

std::timed_mutex m;
int sh; //共享数据
// …
if ( m.try_lock_until(midnight)) {
//对共享数据进行操作
sh += 1;
m.unlock();
}
else {
    //进入临界区失败,在此执行其它代码
}

这里使用midnight是一个冷笑话:对于mutex级别的操作,相应的时间是毫秒级别的而不是小时。

当然地,C++0x中也有recursive_timed_mutex。

mutex可以被看做是一个资源(因为它经常被用来代表一种真实的资源),并且当它对至少两个线程可见时它才是有用的。必然地,mutex不能被复制或者移动(正如你不能复制一个硬件的输入寄存器)。

令人惊讶地,实际中经常很难做到lock()s与unlock()s的匹配。设想一下那些复杂的控制结构,错误以及异常,要做到匹配的确比较困难。如果你可以选择使用locks去管理你的互斥,这将为你和你的用户节省大量的时间,再也不用熬夜通宵彻夜无眠了。(that will save you and your users a lot of sleep??)。

同时可参考:

(翻译:Yibo Zhu)