戈朗 : Make select statemet deterministic?

Question

让我们仔细看看Ticker example code在 Go 的时间包中:

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 channel 同时就绪时，我们进入了 Go 非确定性行为的领域:

A select blocks until one of its cases can run, then it executes that case. It chooses one at random if multiple are ready.

我理解 Go 的设计原理，为什么 select 是非确定性的。它主要归结为语言不敢去解决的问题，因为这样做通常很难，并且可能会导致用户在不知不觉中编写出活泼的代码，从而将选择和练习的优先级留给读者。

让我们假设，无论出于何种原因，我想确保在结束程序并打印 Done! 之前消耗所有挂起的滴答声。是否存在可应用于此简单示例以使其具有确定性的通用转换？

我尝试添加另一个信号 channel :

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!

我们不能保证我们不会在收到最后一个订单号的同时收到停止消息，所以我们只是将问题转移到当它表现“不正确”时会 panic 的东西(这是比默默地这样做稍微好一点)。如果我们niltick channel ，我们将移交给原始案例。而且我们仍然有可能根本没有打印刻度的情况，因为我们有可能在计时器有机会触发之前关闭它......

准备好的 channel 怎么样？

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 个新 channel 和一个额外的 go 例程有关，但到目前为止还没有失败。这种模式在 go 中是惯用的吗？在您想要优先选择其中一个案例的场景中，是否有通用的形式策略来应用这种类型的转换？我遇到的大多数建议都与顺序和嵌套选择有关，它们并不能真正解决问题。

或者，有没有办法说“给我准备好的 channel 列表，这样我就可以选择处理它们的顺序”？

编辑:

添加一些澄清说明:我对保留并发操作的顺序不感兴趣。我同意这是一个愚蠢的尝试。我只是想知道是否准备好处理一组 channel ，并提供我自己的逻辑来指示当多个 channel 同时准备好时要做什么。我基本上对 POSIX select 的 Go 模拟很感兴趣。和/或我对描述通用的“在 Go 中将非确定性选择转换为确定性选择”模式的文献或常识感兴趣。

例如人们是否使用堆包并将数据存入优先级队列并最终从中读取？是否有 x/reflect 样式包使用不安全实现优先选择？是否有一些简单的模式，例如“将所有选择的单 channel 转换为双 channel 样式并将“完成”请求转发给生产者，生产者又应该终止并关闭他们的 channel 然后阻塞 channel 范围循环(有点像我的工作解决方案)？实际上，由于 x、y 等原因锁定共享条件变量。

Answer 1

如果您需要在两个 channel 都启用时选择一个 channel 而不是另一个 channel ，那么您可以进行嵌套选择。如果在选择开始时启用了两个 channel ，这将选择高优先级而不是低优先级:

select {
  case <-highPriority:
     // Deal with it
  default:
     select {
       case <-lowPriority:
         // low priority channel
       default:
     }
}

如果你有 N 个 channel ，有优先级排序，那么你可以尝试循环选择:

for _,channel:=range channels {
   select {
     case <-channel:
      //
     default:
   }
}

这当然是您所需的近似值，因为它会错过循环时发生的 channel 状态变化。但它会根据 for 循环开始时的状态对 channel 进行优先级排序。

然后是reflect.Select，但是那个不会优先。