1:为什么先要锁定条件变量基于的互斥锁,才能调用它的Wait方法?
2:为什么要用for语句来包裹调用其Wait方法的表达式,用if语句不行吗?
这些问题我在面试的时候也经常问。你需要对这个Wait方法的内部机制有所了解才能回答上来。
条件变量的Wait方法主要做了四件事。
- 把调用它的 goroutine(也就是当前的 goroutine)加入到当前条件变量的通知队列中。
- 解锁当前的条件变量基于的那个互斥锁。
- 让当前的 goroutine 处于等待状态,等到通知到来时再决定是否唤醒它。此时,这个 goroutine 就会阻塞在调用这个Wait方法的那行代码上。
- 如果通知到来并且决定唤醒这个 goroutine,那么就在唤醒它之后重新锁定当前条件变量基于的互斥锁。自此之后,当前的 goroutine 就会继续执行后面的代码了。
问题一解答:因为条件变量的Wait方法在阻塞当前的 goroutine 之前,会解锁它基于的互斥锁,所以在调用该Wait方法之前,我们必须先锁定那个互斥锁,否则在调用这个Wait方法时,就会引发一个不可恢复的 panic。为什么条件变量的Wait方法要这么做呢?你可以想象一下,如果Wait方法在互斥锁已经锁定的情况下,阻塞了当前的 goroutine,那么又由谁来解锁呢?别的 goroutine 吗?先不说这违背了互斥锁的重要使用原则,即:成对的锁定和解锁,就算别的 goroutine 可以来解锁,那万一解锁重复了怎么办?由此引发的 panic 可是无法恢复的。如果当前的 goroutine 无法解锁,别的 goroutine 也都不来解锁,那么又由谁来进入临界区,并改变共享资源的状态呢?只要共享资源的状态不变,即使当前的 goroutine 因收到通知而被唤醒,也依然会再次执行这个Wait方法,并再次被阻塞。所以说,如果条件变量的Wait方法不先解锁互斥锁的话,那么就只会造成两种后果:不是当前的程序因 panic 而崩溃,就是相关的 goroutine 全面阻塞。
问题二解答:这主要是为了保险起见。如果一个 goroutine 因收到通知而被唤醒,但却发现共享资源的状态,依然不符合它的要求,那么就应该再次调用条件变量的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)本身提供的条件变量也会如此
来看下signal()代码示列
type User struct { //模拟用户
mail *Mail
}
type Mail struct { //模拟邮箱
mail bool
sendCond *sync.Cond
recvCond *sync.Cond
lock sync.RWMutex
sendName string
recvName string
}
func NewMail() *Mail {
m := Mail{}
m.sendCond = sync.NewCond(&m.lock)
m.recvCond = sync.NewCond(m.lock.RLocker())
return &m
}
func (m *Mail) SendMail() {
m.lock.Lock()
time.Sleep(time.Minute)
if m.mail{
m.sendCond.Wait()
fmt.Println("已经有邮件了等待接收")
}
m.mail = true
fmt.Println("发送了一封邮件给:",m.recvName)
m.lock.Unlock()
m.recvCond.Signal() //向接收者发送消息
}
func (m *Mail) RecvMail() {
m.lock.RLock()
if !m.mail{
fmt.Println("没有邮件,等待邮箱发送邮件")
m.recvCond.Wait()
}
m.mail = false
fmt.Printf("%s收到一封%s发送的邮件\n",m.recvName,m.sendName)
m.lock.RUnlock()
m.sendCond.Signal()
}
func main() {
mail := NewMail()
lock := make(chan struct{},2)
use1 := User{}
use1.mail = mail
use1.mail.sendName = "jacky"
use2 := User{}
use2.mail = mail
use2.mail.recvName = "rose"
//send mail
go func() {
defer func() {
lock <- struct{}{}
}()
for{
use1.mail.SendMail()
time.Sleep(time.Second)
}
}()
go func() {
defer func() {
lock <- struct{}{}
}()
for{
use2.mail.RecvMail()
time.Sleep(time.Second)
}
}()
<-lock
<-lock
}
我们再看下条件变量的Broadcast()通知方法示列
func main() {
// mailbox 代表信箱。
// 0代表信箱是空的,1代表信箱是满的。
var mailbox uint8
// lock 代表信箱上的锁。
var lock sync.Mutex
// sendCond 代表专用于发信的条件变量。
sendCond := sync.NewCond(&lock)
// recvCond 代表专用于收信的条件变量。
recvCond := sync.NewCond(&lock)
// send 代表用于发信的函数。
send := func(id, index int) {
lock.Lock()
for mailbox == 1 {
sendCond.Wait()
}
log.Printf("发送邮件用户%d:准备发送邮件...",index)
mailbox = 1
log.Printf("发送邮件用户%d:发送了一份邮件...",index)
lock.Unlock()
recvCond.Broadcast()
}
// recv 代表用于收信的函数。
recv := func(id, index int) {
lock.Lock()
for mailbox == 0 {
recvCond.Wait()
}
log.Printf("用户%d收到邮件:发现有份邮件待接收...",index)
mailbox = 0
log.Printf("用户%d收到邮件:收到一份邮件...",index)
lock.Unlock()
sendCond.Signal() // 确定只会有一个发信的goroutine。
}
// sign 用于传递演示完成的信号。
sign := make(chan struct{}, 3)
max := 6
go func(id, max int) { // 用于发信。
defer func() {
sign <- struct{}{}
}()
for i := 1; i <= max; i++ {
time.Sleep(time.Millisecond * 500)
send(id, i)
}
}(0, max)
go func(id, max int) { // 用于收信。
defer func() {
sign <- struct{}{}
}()
for j := 1; j <= max; j++ {
time.Sleep(time.Millisecond * 200)
recv(id, j)
}
}(1, max/2)
go func(id, max int) { // 用于收信。
defer func() {
sign <- struct{}{}
}()
for k := 1; k <= max; k++ {
time.Sleep(time.Millisecond * 200)
recv(id, k)
}
}(2, max/2)
<-sign
<-sign
<-sign
}