Question

我正在尝试使用工作池建立通用管道库。我为源，管道和接收器创建了一个接口。您会看到，管道的工作是从输入通道接收数据，对其进行处理，然后将结果输出到通道上。这是其预期的行为：

从输入通道接收数据。
将数据委托给可用的工作人员。
工作者将结果发送到输出通道。
所有工作人员完成后，关闭输出通道。

func (p *pipe) Process(in chan interface{}) (out chan interface{}) {
    var wg sync.WaitGroup
    out = make(chan interface{}, 100)
    go func() {
        for i := 1; i <= 100; i++ {
            go p.work(in, out, &wg)
        }
        wg.Wait()
        close(out)
    }()

    return
}

func (p *pipe) work(jobs <-chan interface{}, out chan<- interface{}, wg *sync.WaitGroup) {
    for j := range jobs {
        func(j Job) {
            defer wg.Done()
            wg.Add(1)

            res := doSomethingWith(j)

            out <- res
        }(j)
    }
}

但是，运行该命令可能会退出而不处理所有输入，或者会显示一条send on closed channel消息而引起恐慌。使用-race标志构建源会在close(out)和out <- res之间发出数据竞争警告。

这是我认为可能会发生的情况。一旦许多工人完成工作，就会有瞬间wg的计数器达到零。因此，完成wg.Wait()，程序前进到close(out)。同时，工作渠道还没有完成数据生成，这意味着一些工作人员仍在运行另一个goroutine。由于out频道已关闭，因此会引起恐慌。

将等待组放置在其他地方吗？还是有更好的方法等待所有工人完成工作？

Answer 1

作业的完成速度可能与发送的速度一样快。在这种情况下，即使有更多项目要处理，WaitGroup也会接近零浮动。

对此的一种解决方法是在发送作业之前添加一个，并在发送所有作业之后减少一个，从而有效地将发送方视为“作业”之一。在这种情况下，最好在发件人中进行wg.Add：

func (p *pipe) Process(in chan interface{}) (out chan interface{}) {
    var wg sync.WaitGroup
    out = make(chan interface{}, 100)
    go func() {
        for i := 1; i <= 100; i++ {
            wg.Add(1)
            go p.work(in, out, &wg)
        }
        wg.Wait()
        close(out)
    }()

    return
}

func (p *pipe) work(jobs <-chan interface{}, out chan<- interface{}, wg *sync.WaitGroup) {
    for j := range jobs {
        func(j Job) {
            res := doSomethingWith(j)

            out <- res
            wg.Done()
        }(j)
    }
}

我在代码中注意到的一件事是为每个作业启动了goroutine。同时，每个作业都循环处理jobs通道，直到清空/关闭为止。似乎没有必要同时做这两个。

Answer 2

目前尚不清楚为什么每个工作要一名工人，但是如果这样做，则可以重组外循环设置（请参阅下面未经测试的代码）。这样一来就消除了对工作池的需求。

尽管如此，始终wg.Add 在剥离任何工人之前。在这里，您将分派100名工人：

var wg sync.WaitGroup
out = make(chan interface{}, 100)
go func() {
    for i := 1; i <= 100; i++ {
        go p.work(in, out, &wg)
    }
    wg.Wait()
    close(out)
}()

因此，您可以这样做：

var wg sync.WaitGroup
out = make(chan interface{}, 100)
go func() {
    wg.Add(100)  // ADDED - count the 100 workers
    for i := 1; i <= 100; i++ {
        go p.work(in, out, &wg)
    }
    wg.Wait()
    close(out)
}()

请注意，您现在可以将wg本身向下移动到剥离工作人员的goroutine中。如果您放弃让每个工人将工作作为新的goroutine剥离的想法，这可以使事情变得更清洁。但是，如果每个工作人员都打算剥离另一个goroutine，则该工作人员本身也必须使用wg.Add，如下所示：

for j := range jobs {
    wg.Add(1)  // ADDED - count the spun-off goroutines
    func(j Job) {
        res := doSomethingWith(j)

        out <- res
        wg.Done()  // MOVED (for illustration only, can defer as before)
    }(j)
}
wg.Done() // ADDED - our work in `p.work` is now done

也就是说，每个匿名函数都是通道的另一个用户，因此在分离出新的goroutine之前，请增加通道用户数（wg.Add(1)）。阅读完输入通道jobs后，请致电wg.Done()（也许是通过更早的defer来完成的，但我在此处最后进行了显示）。

对此进行考虑的关键是wg计算出可以写入该通道的活动goroutine的数量。只有在 no goroutine打算再写一次时，它才会变为零。这样可以安全地关闭通道。

考虑使用更简单（但未经测试）的方法：

func (p *pipe) Process(in chan interface{}) (out chan interface{}) {
    out = make(chan interface{})
    var wg sync.WaitGroup
    go func() {
        defer close(out)
        for j := range in {
            wg.Add(1)
            go func(j Job) {
                res := doSomethingWith(j)
                out <- res
                wg.Done()
            }(j)
        }
        wg.Wait()
    }()
    return out
}

您现在有了一个goroutine，它正在尽可能快地读取in频道，从而分拆工作。除了即将完成工作外，您每份新工作都会获得一个goroutine。没有池，每个工作只有一个工人（与您的代码相同，只不过我们剔除了没有任何用处的池）。

或者，因为只有几个可用的CPU，所以像开始时一样剥离一些goroutine，但是让每个goroutine运行一个作业并完成结果，然后返回阅读下一份工作：

func (p *pipe) Process(in chan interface{}) (out chan interface{}) {
    out = make(chan interface{})
    go func() {
        defer close(out)
        var wg sync.WaitGroup
        ncpu := runtime.NumCPU()  // or something fancier if you like
        wg.Add(ncpu)
        for i := 0; i < ncpu; i++ {
            go func() {
                defer wg.Done()
                for j := range in {
                    out <- doSomethingWith(j)
                }
            }()
        }
        wg.Wait()
    }
    return out
}

使用runtime.NumCPU()可以使读取作业的工人与运行作业的CPU数量一样多。这些是游泳池，它们一次只能完成一项工作。

如果输出通道读取器的结构合理（即，不会导致管道阻塞），通常无需缓冲输出通道。如果不是，则此处的缓冲深度会限制您可以“消耗”任何消耗结果的人的工作数。根据“提前进行”的有用程度进行设置-不一定是CPU数量，预期作业数量或其他。

关闭与发送至频道

2 个答案: