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

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

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

@H_502_4@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提供了屈服的机会.否则就没有.

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

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

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

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

猜你在找的Java相关文章