|
|
# 28 | 条件变量sync.Cond （下）
|
|
|
|
|
|
你好，我是郝林，今天我继续分享条件变量sync.Cond的内容。我们紧接着上一篇的内容进行知识扩展。
|
|
|
|
|
|
## 问题 1：条件变量的`Wait`方法做了什么？
|
|
|
|
|
|
在了解了条件变量的使用方式之后，你可能会有这么几个疑问。
|
|
|
|
|
|
1. 为什么先要锁定条件变量基于的互斥锁，才能调用它的`Wait`方法？
|
|
|
2. 为什么要用`for`语句来包裹调用其`Wait`方法的表达式，用`if`语句不行吗？
|
|
|
|
|
|
这些问题我在面试的时候也经常问。你需要对这个`Wait`方法的内部机制有所了解才能回答上来。
|
|
|
|
|
|
条件变量的`Wait`方法主要做了四件事。
|
|
|
|
|
|
1. 把调用它的goroutine（也就是当前的goroutine）加入到当前条件变量的通知队列中。
|
|
|
2. 解锁当前的条件变量基于的那个互斥锁。
|
|
|
3. 让当前的goroutine处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个goroutine就会阻塞在调用这个`Wait`方法的那行代码上。
|
|
|
4. 如果通知到来并且决定唤醒这个goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此之后，当前的goroutine就会继续执行后面的代码了。
|
|
|
|
|
|
你现在知道我刚刚说的第一个疑问的答案了吗？
|
|
|
|
|
|
因为条件变量的`Wait`方法在阻塞当前的goroutine之前，会解锁它基于的互斥锁，所以在调用该`Wait`方法之前，我们必须先锁定那个互斥锁，否则在调用这个`Wait`方法时，就会引发一个不可恢复的panic。
|
|
|
|
|
|
为什么条件变量的`Wait`方法要这么做呢？你可以想象一下，如果`Wait`方法在互斥锁已经锁定的情况下，阻塞了当前的goroutine，那么又由谁来解锁呢？别的goroutine吗？
|
|
|
|
|
|
先不说这违背了互斥锁的重要使用原则，即：成对的锁定和解锁，就算别的goroutine可以来解锁，那万一解锁重复了怎么办？由此引发的panic可是无法恢复的。
|
|
|
|
|
|
如果当前的goroutine无法解锁，别的goroutine也都不来解锁，那么又由谁来进入临界区，并改变共享资源的状态呢？只要共享资源的状态不变，即使当前的goroutine因收到通知而被唤醒，也依然会再次执行这个`Wait`方法，并再次被阻塞。
|
|
|
|
|
|
所以说，如果条件变量的`Wait`方法不先解锁互斥锁的话，那么就只会造成两种后果：不是当前的程序因panic而崩溃，就是相关的goroutine全面阻塞。
|
|
|
|
|
|
再解释第二个疑问。很显然，`if`语句只会对共享资源的状态检查一次，而`for`语句却可以做多次检查，直到这个状态改变为止。那为什么要做多次检查呢？
|
|
|
|
|
|
**这主要是为了保险起见。如果一个goroutine因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求，那么就应该再次调用条件变量的`Wait`方法，并继续等待下次通知的到来。**
|
|
|
|
|
|
这种情况是很有可能发生的，具体如下面所示。
|
|
|
|
|
|
1. 有多个goroutine在等待共享资源的同一种状态。比如，它们都在等`mailbox`变量的值不为`0`的时候再把它的值变为`0`，这就相当于有多个人在等着我向信箱里放置情报。虽然等待的goroutine有多个，但每次成功的goroutine却只可能有一个。别忘了，条件变量的`Wait`方法会在当前的goroutine醒来后先重新锁定那个互斥锁。在成功的goroutine最终解锁互斥锁之后，其他的goroutine会先后进入临界区，但它们会发现共享资源的状态依然不是它们想要的。这个时候，`for`循环就很有必要了。
|
|
|
|
|
|
2. 共享资源可能有的状态不是两个，而是更多。比如，`mailbox`变量的可能值不只有`0`和`1`，还有`2`、`3`、`4`。这种情况下，由于状态在每次改变后的结果只可能有一个，所以，在设计合理的前提下，单一的结果一定不可能满足所有goroutine的条件。那些未被满足的goroutine显然还需要继续等待和检查。
|
|
|
|
|
|
3. 有一种可能，共享资源的状态只有两个，并且每种状态都只有一个goroutine在关注，就像我们在主问题当中实现的那个例子那样。不过，即使是这样，使用`for`语句仍然是有必要的。原因是，在一些多CPU核心的计算机系统中，即使没有收到条件变量的通知，调用其`Wait`方法的goroutine也是有可能被唤醒的。这是由计算机硬件层面决定的，即使是操作系统（比如Linux）本身提供的条件变量也会如此。
|
|
|
|
|
|
|
|
|
综上所述，在包裹条件变量的`Wait`方法的时候，我们总是应该使用`for`语句。
|
|
|
|
|
|
好了，到这里，关于条件变量的`Wait`方法，我想你知道的应该已经足够多了。
|
|
|
|
|
|
## 问题 2：条件变量的`Signal`方法和`Broadcast`方法有哪些异同？
|
|
|
|
|
|
条件变量的`Signal`方法和`Broadcast`方法都是被用来发送通知的，不同的是，前者的通知只会唤醒一个因此而等待的goroutine，而后者的通知却会唤醒所有为此等待的goroutine。
|
|
|
|
|
|
条件变量的`Wait`方法总会把当前的goroutine添加到通知队列的队尾，而它的`Signal`方法总会从通知队列的队首开始，查找可被唤醒的goroutine。所以，因`Signal`方法的通知，而被唤醒的goroutine一般都是最早等待的那一个。
|
|
|
|
|
|
这两个方法的行为决定了它们的适用场景。如果你确定只有一个goroutine在等待通知，或者只需唤醒任意一个goroutine就可以满足要求，那么使用条件变量的`Signal`方法就好了。
|
|
|
|
|
|
否则，使用`Broadcast`方法总没错，只要你设置好各个goroutine所期望的共享资源状态就可以了。
|
|
|
|
|
|
此外，再次强调一下，与`Wait`方法不同，条件变量的`Signal`方法和`Broadcast`方法并不需要在互斥锁的保护下执行。恰恰相反，我们最好在解锁条件变量基于的那个互斥锁之后，再去调用它的这两个方法。这更有利于程序的运行效率。
|
|
|
|
|
|
最后，请注意，条件变量的通知具有即时性。也就是说，如果发送通知的时候没有goroutine为此等待，那么该通知就会被直接丢弃。在这之后才开始等待的goroutine只可能被后面的通知唤醒。
|
|
|
|
|
|
你可以打开demo62.go文件，并仔细观察它与demo61.go的不同。尤其是`lock`变量的类型，以及发送通知的方式。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
我们今天主要讲了条件变量，它是基于互斥锁的一种同步工具。在Go语言中，我们需要用`sync.NewCond`函数来初始化一个`sync.Cond`类型的条件变量。
|
|
|
|
|
|
`sync.NewCond`函数需要一个`sync.Locker`类型的参数值。
|
|
|
|
|
|
`*sync.Mutex`类型的值以及`*sync.RWMutex`类型的值都可以满足这个要求。另外，后者的`RLocker`方法可以返回这个值中的读锁，也同样可以作为`sync.NewCond`函数的参数值，如此就可以生成与读写锁中的读锁对应的条件变量了。
|
|
|
|
|
|
条件变量的`Wait`方法需要在它基于的互斥锁保护下执行，否则就会引发不可恢复的panic。此外，我们最好使用`for`语句来检查共享资源的状态，并包裹对条件变量的`Wait`方法的调用。
|
|
|
|
|
|
不要用`if`语句，因为它不能重复地执行“检查状态-等待通知-被唤醒”的这个流程。重复执行这个流程的原因是，一个“因为等待通知，而被阻塞”的goroutine，可能会在共享资源的状态不满足其要求的情况下被唤醒。
|
|
|
|
|
|
条件变量的`Signal`方法只会唤醒一个因等待通知而被阻塞的goroutine，而它的`Broadcast`方法却可以唤醒所有为此而等待的goroutine。后者比前者的适应场景要多得多。
|
|
|
|
|
|
这两个方法并不需要受到互斥锁的保护，我们也最好不要在解锁互斥锁之前调用它们。还有，条件变量的通知具有即时性。当通知被发送的时候，如果没有任何goroutine需要被唤醒，那么该通知就会立即失效。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
`sync.Cond`类型中的公开字段`L`是做什么用的？我们可以在使用条件变量的过程中改变这个字段的值吗？
|
|
|
|
|
|
[戳此查看Go语言专栏文章配套详细代码。](https://github.com/hyper0x/Golang_Puzzlers)
|
|
|
|