Go sync.Cond | Go 语言高性能编程 | 极客兔兔

[geektutu]

https://geektutu.com/post/hpg-sync-cond.html

Go 语言/golang 高性能编程，Go 语言进阶教程，Go 语言高性能编程(high performance go)。sync.Cond 是一个条件锁，也被称为条件变量，常用来一写多读(一个 goroutine 通知多个在等待的 goroutines)的场景。

[2lingnil]

这个时候，就需要有个全局的变量来标志第一个协程数据是否接受完毕，剩下的协程，反复简单该变量的值，直到满足要求。

反复简单 应该改为 反复检查？

[Imfan]

done 不是并发安全的

[geektutu]

@2lingnil fixed @Imfan done 前后有锁

[whyming]

除了Signal这个，使用场景和WaitGroup非常相似啊，而且Signal可以用chan自己实现，什么特定场景用Cond更好吗？

[fufay]

这个例子用单个channel做“广播”也可以，只要 close(ch)就代表发送通知了，其他的goroutine使用for select 结构来接收广播就行了。

[kirkzhangtech]

writer 函数里面的c.L.Lock() and c.L.Unlock()没啥作用把？
不能说明什么问题

[ngyhd]

使用示例中，wait既然是阻塞，第五行为什么是用for而不是if呢？

[dablelv]

使用示例中，“互斥锁需要保护的条件变量”，条件变量中的互斥锁并不是用来保护 done 的吧，而是用来互斥加入条件变量的等待队列的吧

[dablelv]

@fufay
这个例子用单个channel做“广播”也可以，只要 close(ch)就代表发送通知了，其他的goroutine使用for select 结构来接收广播就行了。

大佬，确实如此。有想到 sync.Cond 的存在的必要性了吗？

[weirwei]

@ngyhd
使用示例中，wait既然是阻塞，第五行为什么是用for而不是if呢？

文中有写
"对条件的检查，使用了 for !condition() 而非 if，是因为当前协程被唤醒时，条件不一定符合要求，需要再次 Wait 等待下次被唤醒。为了保险起见，使用 for 能够确保条件符合要求后，再执行后续的代码。"

[maifusha]

@whyming
除了Signal这个，使用场景和WaitGroup非常相似啊，而且Signal可以用chan自己实现，什么特定场景用Cond更好吗？

WaitGroup处理多通知一，Cond处理一通知多(且确保并发安全)

[maifusha]

@kirklonglive
writer 函数里面的c.L.Lock() and c.L.Unlock()没啥作用把？
不能说明什么问题

c.L.Lock()是为了Wait函数内部并发安全的将当前协程加入Cond的通知队列，之后会解锁并挂起等待通知。
c.L.Unlock()并不是配对先前你所见的那个c.L.Lock()，而是配对的wait()内部的加锁。wait()获得通知后，并不是立即就退出函数了，wait内部接着是去抢占c.L锁的，以确保对共享资源的并发安全访问。只有当前协程抢占到c.L锁后才会从wait()退出。之后处理你的业务逻辑，最后需要你显式的c.L.Unlock()去解锁wait()退出前的锁定

[maifusha]

@ngyhd
使用示例中，wait既然是阻塞，第五行为什么是用for而不是if呢？

因为存在可能，某个wait协程会把资源状态改回不可用，所以其他wait协程需要二次确认。如果所有wait协程都是只读不写，我也觉着用if就好了