multithreading - 为什么 ZeroMQ 上下文没有在所有 goroutine 之间共享？

Question

在此ZeroMQ example ,

// Multithreaded Hello World server.
// Uses Goroutines.  We could also use channels (a native form of
// inproc), but I stuck to the example.
//
// Author:  Brendan Mc.
// Requires: http://github.com/alecthomas/gozmq

package main

import (
    "fmt"
    zmq "github.com/alecthomas/gozmq"
    "time"
)

func main() {
    // Launch pool of worker threads
    for i := 0; i != 5; i = i + 1 {
        go worker()
    }

    // Prepare our context and sockets
    context, _ := zmq.NewContext()
    defer context.Close()

    // Socket to talk to clients
    clients, _ := context.NewSocket(zmq.ROUTER)
    defer clients.Close()
    clients.Bind("tcp://*:5555")

    // Socket to talk to workers
    workers, _ := context.NewSocket(zmq.DEALER)
    defer workers.Close()
    workers.Bind("ipc://workers.ipc")

    // connect work threads to client threads via a queue
    zmq.Device(zmq.QUEUE, clients, workers)

}

func worker() {
    context, _ := zmq.NewContext()
    defer context.Close()

    // Socket to talk to dispatcher
    receiver, _ := context.NewSocket(zmq.REP)
    defer receiver.Close()
    receiver.Connect("ipc://workers.ipc")

    for true {
        received, _ := receiver.Recv(0)
        fmt.Printf("Received request [%s]\n", received)

        // Do some 'work'
        time.Sleep(time.Second)

        // Send reply back to client
        receiver.Send([]byte("World"), 0)
    }
}

每个 goroutine 都有自己的 ZeroMQ Context。然而，在 ZeroMQ guide ，它说了以下内容:

Create one ZeroMQ context at the start of your process, and pass thatto all threads that you want to connect via inproc sockets.

Don't share ZeroMQ sockets between threads. ZeroMQ sockets are notthreadsafe. Technically it's possible to migrate a socket from onethread to another but it demands skill. The only place where it'sremotely sane to share sockets between threads are in languagebindings that need to do magic like garbage collection on sockets.

我知道 goroutines 不是线程。

相反，它们存在于线程中。但我也读到，在 goroutine 之间可以有一个共享对象。

那么，为什么不在 goroutine 之间共享上下文？

我认为它会占用更少的空间，因为其中包含套接字的上下文可能有点大。

但即使它没有那么消耗，为什么在这个例子中根本没有共享上下文？

Answer 1

问:为什么在 goroutine 之间不共享上下文？^{(在示例中)}

除了确实共享 Context 实例的_{(相当极端)} 技术选项(在某些合理的情况/场合下)，演示的代码段还侧重于零共享，作为一般原则，ZeroMQ 是为数不多的零格言之一，因此众所周知。

采用一组不连续的 Context 实例(在同一个线程中，一个实例也可能有多个这样的实例)是有好处的。性能缩放:

• 从广义上讲，实例之间的工作负载分离

• 在更狭义的意义上，直接 IO 线程缩放(在 Context 实例化时定义不同数量的 IO 线程，一些只有 1 个 IO 线程，而其他可能有 2、3 或 10 个 IO 线程用于高性能数据泵引擎)并通过基于setsockopt( ZMQ_AFFINITY ... ) 的套接字到 IO 线程映射使用位掩码映射，它允许将一些传输任务直接分离到不同的、discjunct Context-instances，并且还可以更具体地处理不同的传输流量优先级模式，通过使用Context-instances 的 IO 线程的单独的专门组(自然地，有意识地配备了更多不同数量的底层 ZeroMQ Context IO线程)。对于性能扩展和几乎确定性的流量策略处理实现而言，这是一项非常宝贵的功能。

这可能会激发您进一步思考此类细粒度管理(粒度)如何帮助您的分布式应用程序更好地利用 ZeroMQ 框架的服务，以及这种零共享概念如何为您打开性能扩展和吞吐量限制的新世界。

如有疑问，请注意源代码中开头的注释:

...
// Uses Goroutines.  We could also use channels (a native form of
// inproc), but I stuck to the example.
...

inproc:// 传输类是关于如何从非共享、非阻塞上下文实例中获益并享受几乎线性扩展的明显示例-up，达到峰值性能。