12

我写了以下程序：

package main

import (
    "fmt"
)

func processevents(list chan func()) {
    for {
        //a := <-list
        //a()
    }
}

func test() {
    fmt.Println("Ho!")
}

func main() {

    eventlist := make(chan func(), 100)

    go processevents(eventlist)

    for {
        eventlist <- test
        fmt.Println("Hey!")
    }
}

由于通道事件列表是一个缓冲通道，我想我应该得到输出“嘿！”的 100 倍，但它只显示一次。我的错误在哪里？

4

3 回答 3

23

更新（Go 版本 1.2+）

从 Go 1.2 开始，调度程序的工作原理是抢占式多任务。这意味着原始问题中的问题（以及下面提供的解决方案）不再相关。

来自Go 1.2 发行说明

调度程序中的抢占

在以前的版本中，一个永远循环的 goroutine 可能会饿死同一线程上的其他 goroutine，当 GOMAXPROCS 只提供一个用户线程时，这是一个严重的问题。在 Go > 1.2 中，这部分得到了解决：调度程序在进入函数时偶尔被调用。这意味着任何包含（非内联）函数调用的循环都可以被抢占，从而允许其他 goroutine 在同一线程上运行。

简短的回答

它不会阻止写入。它陷入了无限循环processevents。这个循环永远不会屈服于调度程序，导致所有 goroutine 无限期地锁定。

如果您注释掉对 的调用processevents，您将得到预期的结果，直到第 100 次写入。此时程序会出现恐慌，因为没有人从通道中读取。

runtime.Gosched()另一种解决方案是在循环中调用 to 。

长答案

在 Go1.0.2 中，Go 的调度程序基于Cooperative multitasking的原则工作。这意味着它通过让这些例程在特定条件下与调度程序交互来将 CPU 时间分配给在给定 OS 线程中运行的各种 goroutine。这些“交互”发生在 goroutine 中执行某些类型的代码时。在 go 的情况下，这涉及到执行某种 I/O、系统调用或内存分配（在某些条件下）。

在空循环的情况下，不会遇到这样的情况。因此，只要该循环正在运行，就永远不允许调度程序运行其调度算法。因此，这可以防止它将 CPU 时间分配给等待运行的其他 goroutine，并且您观察到的结果随之而来：您有效地创建了一个无法被调度程序检测或打破的死锁。

空循环在 Go 中通常是不需要的，并且在大多数情况下表明程序中存在错误。如果出于某种原因确实需要它，则必须通过runtime.Gosched()在每次迭代中调用来手动让步给调度程序。

for {
    runtime.Gosched()
}

作为解决方案提到了设置GOMAXPROCS一个值。> 1虽然这将消除您观察到的直接问题，但如果调度程序决定将循环 goroutine 移动到它自己的 OS 线程，它将有效地将问题移动到不同的 OS 线程。除非您runtime.LockOSThread()在processevents函数开始时调用，否则无法保证这一点。即使那样，我仍然不会依赖这种方法来成为一个好的解决方案。简单地调用runtime.Gosched()循环本身，将解决所有问题，无论 goroutine 在哪个操作系统线程中运行。

于 2012-09-13T19:41:53.917 回答
9

这是另一种解决方案 - 用于range从通道中读取。此代码将正确地屈服于调度程序，并在通道关闭时正确终止。

func processevents(list chan func()) {
    for a := range list{
        a()
    }
}
于 2012-09-14T07:02:50.007 回答
1

好消息，自 Go 1.2（2013 年 12 月）以来，原始程序现在可以按预期运行。您可以在 Playground 上尝试一下。

这在Go 1.2 发行说明中的​​“调度程序中的抢占”部分中进行了解释：

在以前的版本中，一个永远循环的 goroutine 可能会饿死同一线程上的其他 goroutine，当 GOMAXPROCS 只提供一个用户线程时，这是一个严重的问题。在 Go 1.2 中，这部分得到了解决：调度程序在进入函数时偶尔被调用。

于 2013-12-30T09:31:01.740 回答