精选留言(41)

• 
  hello peter

  2018-10-26

  老师, 感觉这个送信的例子似乎用chanel实现更简单.在网上也查了一些例子, 发现都可以用chanel替代. 那使用sync.Cond 的优势是什么呢, 或者有哪些独特的使用场景?

  作者回复: 优势是并发流程上的协同，chan的主要任务是传递数据。另外cond是更低层次的工具，效率更高一些，但是肯定没有chan方便。

  共 2 条评论

  36
• 
  属雨

  2018-10-12

  个人理解，不确定对不对，请老师评判一下： 因为Go语言传递对象时，使用的是浅拷贝的值传递，所以，当传递一个Cond对象时复制了这个Cond对象，但是低层保存的L(Locker类型)，noCopy(noCopy类型)，notify(notifyList类型)，checker(copyChecker)对象的指针没变，因此，*sync.Cond和sync.Cond都可以传递。

  作者回复: 基本正确。Locker是接口，是引用类型，nocopy是结构体，所以直接拷贝值的话，底层锁还是用的同一个，使用上容易出问题。

  

  31
• 
  传说中的成大大

  2020-04-09

  这几天一直对条件变量的理解比较模糊，但是我想既然要学就学好 于是又去翻了Unix环境高级编程 总算把它跟互斥锁区分开了 互斥锁 是对一个共享区域进行加锁 所有线程都是一种竞争的状态去访问 而条件变量 主要是通过条件状态来判断，实际上他还是会阻塞 只不过不会像互斥锁一样去参与竞争，而是在哪里等待条件变量的状态发生改变过后的通知 再被唤醒

  作者回复: 👍

  

  15
• 
  Geek_a8be59

  2019-08-12

  var mailbox uint8 var lock sync.RWMutex sendCond := sync.NewCond(&lock) recvCond := sync.NewCond(&lock) 为什么不能向上面那样都用同一个互斥量，非要两个不同呢？老师，能讲一下区别么

  作者回复: 如果都用同一个互斥量的话，操作双方就无法独立行事，这就是完全串行的操作了，效率上会大打折扣。 进一步说，本来就是一个发一个收，理应一个用写锁一个用读锁，这样效率高，之后扩展起来也方便。因为读之间不用互斥。

  共 3 条评论

  13
• 
  疯琴

  2019-12-10

  秘密接头的类比形象生动，学习过程轻松有趣又不失深度。

  

  7
• 
  文@雨路

  2018-10-12

  指针可以传递，值不可以，传递值会拷贝一份，导致出现两份条件变量，彼此之间没有联系

  

  6
• 
  🐻

  2019-04-09

  需传递 *sync.Cond 因为 Cond 结构体中的 notify 变量和 checker 变量都是值类型，传递sync.Cond 会复制值，这样两个锁保留的被阻塞的 Goroutine 就不同了。

  

  6
• 
  beiliu

  2018-12-31

  您好，老师，官方文档是建议，singal在锁住的情况下使用的“Signal唤醒等待c的一个线程（如果存在）。调用者在调用本方法时，建议（但并非必须）保持c.L的锁定“

  

  5
• 
  ming

  2018-12-17

  多routine从信箱中获取情报, 都在等mailbox变量的值不为0的时候再把它的值变为0， 这个 RLock 限制不了写操作，可能会有多个routine同时将 mailbox 变为0的，跟文中的场景有些不合。 不知道我理解的有没有问题

  共 3 条评论

  5
• 
  q

  2020-11-03

  个人感觉，从底层原理解释条件变量可能更容易理解

  

  4
• 
  郭星

  2020-09-02

  在for 循环中使用 wait,在我的测试中,当条件变量处于wait状态时,如果没有唤醒,当前协程会一直阻塞等待在wait这行代码,因此使用for 和 使用if 实际最终结果是相同的,为什么要使用for呢? package lesson27 import ( "sync" "testing" "time" ) // 利用条件变量实现协调多协程发取信件操作 func TestCond(t *testing.T) { var wg sync.WaitGroup var mu sync.RWMutex // 信箱 mail := false // 两个条件变量 // 发送信条件变量 sendCond := sync.NewCond(&mu) // 接收信条件变量, 对于接收实际是只读操作,因此只需要使用读锁就可以 receiveCond := sync.NewCond(mu.RLocker()) // 最大发送接收次数 max := 5 wg.Add(2) // 发送人协程 go func(i int) { for ; i > 0; i-- { time.Sleep(time.Second * 3) mu.Lock() // 如果信箱不为空,则需要等待 //for mail { if mail { // 发送者等待 t.Log("sendCond准备进入等待队列") sendCond.Wait() t.Log("sendCond进入等待队列") } mail = true t.Log("发送信件成功") mu.Unlock() // 通知发送者 receiveCond.Signal() t.Log("唤醒receiveCond") } wg.Done() }(max) go func(i int) { for ; i > 0; i-- { mu.RLock() //for !mail { if !mail { //接收者等待 t.Log("receiveCond准备进入等待队列") receiveCond.Wait() // 如果没有被唤醒会一直阻塞在此 t.Log("receiveCond进入等待队列") } mail = false t.Log("获取信件成功") mu.RUnlock() // 通知接收者 sendCond.Signal() t.Log("唤醒sendCond") } wg.Done() }(max) wg.Wait() }

  展开

  作者回复: 我在文章里说了啊，有可能会碰到“假唤醒”的情况。而且，如果存在“有多个wait但只需唤醒一个”的情况，也需要用for语句。在for语句里，唤醒后可以再次检查状态，如果状态符合就开始后续工作，如果不符合就再次wait。用if语句就办不到。

  

  4
• 
  会玩code

  2020-05-15

  老师，不懂这里的recvCond为什么可以用读锁呢？这里也是有对资源做操作的呀（将mailbox置为0），用读锁不会有问题吗？

  作者回复: 在只有一个“取信者”的情况下，这里使用读锁是没问题的。但如果有多个“取信者”就需要用写锁啦。你可以看一看下一篇文章对应的demo文件（demo62.go），其中就有多个“取信者”的演示。

  共 2 条评论

  2
• 
  啦啦啦

  2022-06-07

  想请问下老师，两个goroutine都使用了同一把锁，26讲（Mutex）里不是说明，尽量使用：是让每一个互斥锁都只保护一个临界区或一组相关临界区。有点搞不明白，望老师指点 go func(max int) { // 用于发信。 defer func() { sign <- struct{}{} }() for i := 1; i <= max; i++ { time.Sleep(time.Millisecond * 500) 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() recvCond.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 { recvCond.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)

  展开

  作者回复: “一组相关临界区”可以是操作同一个共享资源的多段代码，也可以是在逻辑上有强相关关系的多段代码。在这里，这两段代码都是针对 mailbox 变量的，属于前者。只不过其中还夹杂了 不同条件变量 的 Wait 操作。 我总体再说一下吧，我们可以从两个维度来理解互斥锁的保护作用： 1. 多个goroutine并发执行同一段代码（如一个函数或方法），且这段代码访问或修改了共享的状态或资源。这时候，我们需要使用互斥锁保护这段代码。这相当于保护了那个共享状态或资源。这里的“这段代码”就是一个临界区。 2. （如本例）多个goroutine中的代码（确切地说，是go函数）直接访问或修改了共享的状态或资源。这时候，我们往往就需要使用同一个互斥锁同时去保护那几段相关的代码。这里的几段代码各自成为独立的临界区，但它们是相关的。这就是我说的“一组相关的临界区”。 以上这两个维度说的就是互斥锁的常用场景。一个是“单段代码的并发执行”，一个是“多段代码的各自执行（也是并发执行）”。关键是，不管是单段代码还是多段代码，它们都分别访问了同一个共享的东西。

  

  2
• 
  lesserror

  2021-08-15

  郝林老师，demo61.go 中的 两个go function（收信 和 发信），是怎么保证先 发信 后收信的呢？ 不是说 go function 函数 的执行 是 随机的么？ 我打印了很多遍，发现 都是执行的 发信 操作，然后是 收信 操作。

  作者回复: 正因为有了条件变量才会有这样的同步状态啊。条件变量就相当于信号弹的发射器。 双方各有一个信号弹发射器（就像示例程序中的 sendCond 和 recvCond）并互相发送信号，这就是 demo61 所做的。 这个程序你也可以这样理解： A 和 B 在下象棋。步骤如下： A 走了一步棋，并发送信号示意让 B 走一步； B 收到信号走了一步棋，然后反过来向 A 发送信号示意“我走了一步，该你了”； A 再走一步棋，并再次发射信号示意让 B 再走一步； B 再走一步后，再发射信号告诉 A； 如此循环往复。 再做一个类比： 单个条件变量用于“教官”指挥“士兵”，“教官”只能有一个，而“士兵”可以有多个（demo61 中只有一个士兵）。在 demo61 中，我们又多加了一个用于“反馈”的信号弹发射器。这样一来，“士兵”按照指挥行进一步之后，就可以及时告诉指挥官并请求下一步的行动了。

  

  2
• 
  www

  2020-06-28

  这篇讲解太棒了，看了lock.RLocker()的源码，又返回去看了前面第14篇讲解接口的文章。多看多写，逐步提升

  

  1
• 
  😳

  2020-04-22

  这个类比生动形象，很有趣，简单易懂

  

  1
• 
  Lywane

  2020-03-27

  recvCond.Signal()表示接收方可以接受了，发送这个信号的是发送方。 sendCond.Signal()表示发送方可以再次发送了，发送这个信号的是接收方。

  

  1
• 
  lfn

  2020-01-16

  打卡，2020-01-16.

  

  1
• 
  党

  2019-07-29

  demo60太经典了 不仅体会到了锁的用法 还体会到了 如何利用chan 阻塞主线程 以使goroutine完全跑完 算是chan经典用法吧

  共 1 条评论

  1
• 
  ...

  2019-02-20

  老师 wait会释放锁吗

  作者回复: 每次执行结束前都会释放，要不其他goroutine没法进入锁保护的临界区。

  共 3 条评论

  1