07 | Cond：条件变量的实现机制及避坑指南

老师，上节课你提到noCopy，是一个辅助的、用来帮助 vet 检查用的类型，而Cond还有个copyChecker 是一个辅助结构，可以在运行时检查 Cond 是否被复制使用。 nocpoy是静态检查，copyChecker是运行时检查，不是理解是否正确？ 另外不是是否有其他区别呢？

关于Cond还有一种会不小心误用的场景，因为一些原因导致Wait执行的时候，Signal/Broadcast就已经执行完了，导致Wait一直等待无法唤醒。比如这里的例子 https://stackoverflow.com/questions/36857167/how-to-correctly-use-sync-cond

还是没有想明白k8s为什么不能用channel通知 close可以实现broadcast的功效，在pop的时候，也是只有一个goroutine可以拿到数据，感觉除了关闭队列之外，不存在需要broadcast的情况。也就是感觉不需要多次broadcast，这样channel应该是满足要求的……请老师明示

请教一个问题，nocpoy 是用于 vet 静态检查，copyChecker 是为了运行时检查，都是为了检查 copy 问题，为啥 Cond 要在两处检查，而 Mutex 只需要一处？

func main() { c := sync.NewCond(&sync.Mutex{}) var ready int for i := 0; i < 10; i++ { go func(i int) { time.Sleep(time.Duration(rand.Int63n(10)) * time.Second) // 加锁更改等待条件 c.L.Lock() ready++ c.L.Unlock() log.Printf("运动员#%d 已准备就绪\n", i) // 广播唤醒所有的等待者 c.Broadcast() }(i) } c.L.Lock() for ready != 10 { c.Wait() log.Println("裁判员被唤醒一次") } c.L.Unlock() //所有的运动员是否就绪 log.Println("所有运动员都准备就绪。比赛开始，3，2，1, ......") } 这个例子有问题吧. 这里的 ready 变量共享了变量 c 的锁. 会导致在 c.Wait() 语句执行前 for 中的 goroutine 全部堵塞. 在 c.Wait() 前加句 time.Sleep(time.Second * 10) 试试就知道了. 是不是应该给 ready 变量单独定义一个 Mutex?

有个问题，为什么 Mutex 不使用 copyChecker 来检测是否被复制呢？

文章中在描述 Cond 的复杂性时，说明了 3 点，第三点：「条件变量的更改」 是否可需改为：「等待条件的更改」？

老师请教一个问题，如果Wait前加锁，然后执行完Wait又Unlock有什么作用，我把Wait后面的Unlock去掉，好似程序也能正常运行。是我漏了什么？

老师，Kubernetes PriorityQueue的那个Pop方法里没有使用p.cond.L.Lock()方法，他们是怎么防止不出现释放未加锁的panic啊。

每次调用wait前都要加锁，为啥加锁语句放在了fo的外面？第二次wait是不是就没有加锁了？