GO的条件变量sync.Cond

最新推荐文章于 2024-04-13 08:54:45 发布

原创最新推荐文章于 2024-04-13 08:54:45 发布 · 473 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#golang

Go 专栏收录该内容

48 篇文章

订阅专栏

本文详细介绍了GO中条件变量sync.Cond的使用，包括它与互斥锁的关系、使用方法，尤其是Wait方法的工作原理，强调了在调用Wait前需要锁定互斥锁的重要性，并解释了为何通常使用for循环包裹Wait方法的原因。

GO的条件变量

文章目录

GO的条件变量

一、条件变量与互斥锁

条件变量是基于互斥锁的，它必须基于互斥锁才能发挥作用；
条件变量并不是用来保护临界区和共享资源的，它是用来协调想要访问共享资源的那些线程的；
在Go语言中，条件变量最大的优势是效率方面的提升。当共享资源不满足条件的时候，想操作它的线程不用循环往返地检查了，只要等待通知就好了。

二、条件变量与互斥锁的配合使用

条件变量的初始化离不开互斥锁，并且它的方法有点也是基于互斥锁的。

条件变量提供的三个方法：等待通知（wait）、单发通知（signal）、广发通知（broadcast）。

三、条件变量的使用

（1）创建锁和条件

	// mailbox 代表信箱
	// 0 代表信箱是空的，1代表信箱是满的
	var mailbox uint8
	// lock 代表信箱上的锁
	var lock sync.RWMutex
	// sendCond 代表专用于发信的条件变量
	var sendCond = sync.NewCond(&lock)
	// reveCond 代表专用于收信的条件变量
	var reveCond = sync.NewCond(lock.RLocker())

sync.Cond类型并不是开箱即用的，只能利用sync.NewCond创建它的指针值。这个函数需要sync.Locker类型的参数值。
sync.Locker是一个接口，它包含两个指针方法，即Lock()和Unlock()；因此，sync.Mutex 和sync.RWMutex这两个类型的指针类型才是sync.Locker接口的实现类型。
上面lock变量的Lock方法和Unlock方法分别用于对其中写锁的锁定和解锁，它们与sendCond变量的含义对应。
lock.RLocker()得到的值，拥有Lock和Unlock方法，其内部会分别调用lock变量的RLock方法和RUnlock方法；

（2）使用

lock.Lock()
for mailbox == 1 {
 sendCond.Wait()
}
mailbox = 1
lock.Unlock()
recvCond.Signal()

lock.RLock()
for mailbox == 0 {
 recvCond.Wait()
}
mailbox = 0
lock.RUnlock()
sendCond.Signal()

完整代码：

package main

import (
	"log"
	"sync"
	"time"
)

func main() {
	// mailbox 代表信箱
	// 0 代表信箱是空的，1代表信箱是满的
	var mailbox uint8
	// lock 代表信箱上的锁
	var lock sync.RWMutex
	// sendCond 代表专用于发信的条件变量
	var sendCond = sync.NewCond(&lock)
	// reveCond 代表专用于收信的条件变量
	var reveCond = sync.NewCond(lock.RLocker())

	// sign 用于传递演示完成的信号
	sign := make(chan struct{}, 2)
	max := 5
	go func(max int) { // 用于发信
		defer func() {
			sign <- struct{}{}
		}()
		for i := 1; i <= max; i++ {
			time.Sleep(time.Millisecond * 5)
			lock.Lock()
			for mailbox == 1 {
				sendCond.Wait()
			}
			log.Printf("sender [%d]: the mailbox is empty.", i)
			mailbox = 1
			log.Printf("sender [%d]: the letter has been sent.", i)
			lock.Unlock()
			reveCond.Signal()
		}
	}(max)
	go func(max int) { // 用于收信
		defer func() {
			sign <- struct{}{}
		}()
		for j := 1; j <= max; j++ {
			time.Sleep(time.Millisecond * 500)
			lock.RLock()
			for mailbox == 0 {
				reveCond.Wait()
			}
			log.Printf("receiver [%d]: the mailbox is full.", j)
			mailbox = 0
			log.Printf("receiver [%d]: the letter has been received.", j)
			lock.RUnlock()
			sendCond.Signal()
		}
	}(max)

	<-sign
	<-sign
}

四、条件变量的Wait方法做了什么

（1）条件变量Wait方法主要做的四件事

条件变量的Wait方法主要做了四件事：

把调用它的goroutine（也就是当前goroutine）加入到当前条件变量的通知队列中；
解锁当前条件变量基于的那个互斥锁；
让当前的goroutine处于等待状态，等到通知到来时再决定是否唤醒它。此时，这个goroutine就会阻塞在调用这个Wait方法的那行代码上；
如果通知到来并决定唤醒这个goroutine，那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此以后，当前的goroutine就会继续执行后面的代码了。

（2）为什么要先要锁定条件变量基于的互斥锁，才能调用它的wait方法

因为条件变量的wait方法在阻塞当前的goroutine之前，会解锁它基于的互斥锁。所以在调用wait方法之前，必须先锁定这个互斥锁，否则在调用这个wait方法时，就会引发一个不可恢复的panic。

如果条件变量的Wait方法不先解锁互斥锁的话，那就会造成两个后果：不是当前的程序因panic而崩溃，就是相关的goroutine全面阻塞。

（3）为什么用for语句来包裹调用的wait方法表达式，用if语句不行吗

if语句只会对共享资源的状态检查一次，而for语句却可以做多次检查，直到这个状态改变为止。

之所以做多次检查，主要是为了保险起见。如果一个goroutine因收到通知而被唤醒，但却发现共享资源的状态，依然不符合它的要求i，那么就应该再次调用条件变量的Wait方法，并继续等待下次通知的到来。

这种情况是很有可能发生的，具体如下面所示：

有多个 goroutine 在等待共享资源的同一种状态。比如，它们都在等mailbox变量的值不为0的时候再把它的值变为0，这就相当于有多个人在等着我向信箱里放置情报。虽然等待的 goroutine 有多个，但每次成功的 goroutine 却只可能有一个。别忘了，条件变量的Wait方法会在当前的 goroutine 醒来后先重新锁定那个互斥锁。在成功的 goroutine 最终解锁互斥锁之后，其他的 goroutine 会先后进入临界区，但它们会发现共享资源的状态依然不是它们想要的。这个时候，for循环就很有必要了。
共享资源可能有的状态不是两个，而是更多。比如，mailbox变量的可能值不只有0和1，还有2、3、4。这种情况下，由于状态在每次改变后的结果只可能有一个，所以，在设计合理的前提下，单一的结果一定不可能满足所有 goroutine 的条件。那些未被满足的 goroutine 显然还需要继续等待和检查。
有一种可能，共享资源的状态只有两个，并且每种状态都只有一个 goroutine 在关注，就像我们在主问题当中实现的那个例子那样。不过，即使是这样，使用for语句仍然是有必要的。原因是，在一些多 CPU 核心的计算机系统中，即使没有收到条件变量的通知，调用其Wait方法的 goroutine 也是有可能被唤醒的。这是由计算机硬件层面决定的，即使是操作系统（比如 Linux）本身提供的条件变量也会如此。

综上所述，在包裹条件变量的Wait方法的时候，我们总是应该使用for语句。

不要用if语句，因为它不能重复地执行“检查状态 - 等待通知 - 被唤醒”的这个流程。