让我们仔细看一下Go语言时间包中Ticker示例代码:
package main
import (
"fmt"
"time"
)
func main() {
ticker := time.NewTicker(time.Second)
defer ticker.Stop()
done := make(chan bool)
go func() {
time.Sleep(10 * time.Second)
done <- true
}()
for {
select {
case <-done:
fmt.Println("Done!")
return
case t := <-ticker.C:
fmt.Println("Current time: ", t)
}
}
}
本示例中将时间间隔调整为1秒,方便起见。在运行足够次数后,我们发现存在这样一种情况,即当前时间未被打印(或者仅打印了9次而不是10次):
Current time: 2020-06-10 12:23:51.189421219 -0700 PDT m=+1.000350341
Done!
Current time: 2020-06-10 12:23:52.193636682 -0700 PDT m=+1.000473686
Done!
Current time: 2020-06-10 12:23:53.199688564 -0700 PDT m=+1.000322824
Done!
Current time: 2020-06-10 12:23:54.204380186 -0700 PDT m=+1.000420293
Done!
Current time: 2020-06-10 12:23:55.21085129 -0700 PDT m=+1.000266810
Done!
Done!
Current time: 2020-06-10 12:23:57.220120615 -0700 PDT m=+1.000479431
Done!
Current time: 2020-06-10 12:23:58.226167159 -0700 PDT m=+1.000443199
Done!
Current time: 2020-06-10 12:23:59.231721969 -0700 PDT m=+1.000316117
Done!
当done和ticker.C通道同时就绪时,我们进入了Go非确定性行为的领域: 我理解Go之所以选择select是非确定性的设计原理。这在很大程度上归结于该语言不致力于解决问题,因为这样做通常很困难,并且可能会导致用户编写并发问题代码,因此优先考虑使用select来留给读者练习。
假设出于任何原因,我想确保在关闭程序并打印“完成!”之前消耗所有未处理的ticks。是否存在一般性的转换可以应用于此简单示例使其具有确定性?
我尝试添加另一个信号通道:
func main() {
ticker := time.NewTicker(time.Second)
stop := make(chan bool)
done := make(chan bool)
tick := make(chan time.Time)
go func() {
time.Sleep(1 * time.Second)
stop <- true
}()
go func() {
for t := range tick {
fmt.Println("Current time: ", t)
}
done <- true
}()
for {
select {
case <-stop:
ticker.Stop()
close(tick)
case t := <-ticker.C:
tick <- t
break
case <-done:
fmt.Println("Done!")
return
}
}
}
但似乎表现更差了...
Current time: 2020-06-10 13:23:20.489040642 -0700 PDT m=+1.000425216
Done!
Current time: 2020-06-10 13:23:21.495263288 -0700 PDT m=+1.000338902
Done!
Current time: 2020-06-10 13:23:22.501474055 -0700 PDT m=+1.000327127
Done!
Current time: 2020-06-10 13:23:23.503531868 -0700 PDT m=+1.000244398
Done!
Current time: 2020-06-10 13:23:24.510210786 -0700 PDT m=+1.000420955
Done!
Current time: 2020-06-10 13:23:25.516500359 -0700 PDT m=+1.000460986
Done!
Done!
Current time: 2020-06-10 13:23:27.527077433 -0700 PDT m=+1.000375330
Done!
Current time: 2020-06-10 13:23:28.533401667 -0700 PDT m=+1.000470273
Done!
panic: send on closed channel
goroutine 1 [running]:
main.main()
/home/dcow/Desktop/ticker-go/main2.go:29 +0x22f
Current time: 2020-06-10 13:23:30.547554719 -0700 PDT m=+1.000399602
Done!
Current time: 2020-06-10 13:23:31.55416725 -0700 PDT m=+1.000443683
Done!
Current time: 2020-06-10 13:23:32.56041176 -0700 PDT m=+1.000436364
Done!
Done!
Current time: 2020-06-10 13:23:34.572550584 -0700 PDT m=+1.000445593
Done!
Current time: 2020-06-10 13:23:35.578672712 -0700 PDT m=+1.000357330
Done!
Done!
Current time: 2020-06-10 13:23:37.590984117 -0700 PDT m=+1.000447504
Done!
我们不能保证在接收到最终的tick时不会同时收到停止信号,因此我们只是将问题转化为了一些在行为“不正确”时会出现panic的情况(这比默默地出现要好得多)。如果我们将tick通道置为空,则会退化到原始情况。而且我们仍然有一些情况下根本不会打印任何tick,可能是因为在计时器有机会触发之前就关闭了它。
那么,准备好的通道怎么样?
func main() {
ticker := time.NewTicker(time.Second)
tick := make(chan time.Time)
ready := make(chan bool, 1)
stop := make(chan bool)
done := make(chan bool)
go func() {
time.Sleep(1 * time.Second)
<-ready
stop <- true
}()
go func() {
for t := range tick {
fmt.Println("Current time: ", t)
}
done <- true
}()
for {
select {
case <-stop:
ticker.Stop()
close(tick)
case t := <-ticker.C:
select {
case ready<-true:
break
default:
}
tick <- t
break
case <-done:
fmt.Println("Done!")
return
}
}
}
这似乎有效。增加了3个新通道和一个额外的协程,但到目前为止还没有失败。这种模式在 Go 中是否惯用?在想要优先考虑选择案例的情况下,有哪些一般的形式策略可以应用此类型的转换? 我遇到的大多数建议都涉及顺序和嵌套选择,这并不能真正解决问题。
或者,有没有一种方法可以说“给我准备就绪的通道列表,以便我选择处理它们的顺序”?
编辑:
添加一些澄清的话:我不感兴趣保留并发操作的顺序。我同意这是一个愚蠢的尝试。 我只想知道是否有一组可选的通道已准备好被处理,并提供自己的逻辑来决定在多个通道同时准备好时该怎么做。我基本上对 Go 的 POSIX select
感兴趣。和/或我对描述或围绕通用“将非确定性选择转换为确定性选择的模式”的文献感兴趣。
例如,人们是否使用 heap 包并将数据存入优先级队列,最终从中读取? 是否有一个 x/reflect 风格的包,使用不安全的方法实现了优先选择? 是否有一些简单的模式,比如“将所有应该优先考虑的单通道选择转换为双通道样式,并将“完成”请求转发给生产者,后者应该终止并关闭他们的通道,然后在通道范围循环上阻塞(有点像我的工作解决方案)? 实际上,由于原因 x、y 等等,在共享条件变量上锁定。
select
的每个解决方案仍将存在边缘情况,但这只是我的猜测,抱歉。 - Oleg Kovalov