并发 – 打印到stdout导致阻止的goroutine运行?

前端之家收集整理的这篇文章主要介绍了并发 – 打印到stdout导致阻止的goroutine运行?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
作为一个愚蠢的基本线程练习,我一直在尝试在golang中实现 sleeping barber problem.有渠道这应该很容易,但我遇到了heisenbug.也就是说,当我尝试诊断它时,问题就消失了!

考虑以下. main()函数将整数(或“客户”)推送到商店渠道. barber()阅读商店频道以剪掉“顾客”的头发.如果我将fmt.Print语句插入customer()函数,程序将按预期运行.否则,理发师()永远不会削减任何人的头发.

package main

import "fmt"

func customer(id int,shop chan<- int) {
    // Enter shop if seats available,otherwise leave
    // fmt.Println("Uncomment this line and the program works")
    if len(shop) < cap(shop) {
        shop <- id
    }
}

func barber(shop <-chan int) {
    // Cut hair of anyone who enters the shop
    for {
        fmt.Println("Barber cuts hair of customer",<-shop)
    }
}

func main() {
    shop := make(chan int,5) // five seats available
    go barber(shop)
    for i := 0; ; i++ {
        customer(i,shop)
    }
}

知道正在发生什么吗?

解决方法

问题是Go的调度程序的实现方式.只有在进行系统调用或阻塞通道操作时,当前goroutine才能产生其他goroutine. fmt.Println进行系统调用,为goroutine提供了屈服的机会.否则就没有.

在实践中,这通常并不重要,但对于像这样的小问题,它有时会突然出现.

此外,在频道上进行非阻塞发送的更惯用,更少生动的方式是:

func customer(id int,otherwise leave
    select {
    case shop <- id:
    default:
    }
}

你这样做的方式,客户可能最终会在理发店外等待,因为当你实际发送邮件时,len(商店)可能已经改变了.

猜你在找的Java相关文章