我会遇到 python 的全局解释器锁的问题吗？

Question

我知道这个问题相当高级，可能含糊不清。请询问您是否需要更多详细信息，我会尝试编辑。

我正在使用 QuickFix 和 Python 绑定来同时使用来自大约 30 个市场的高吞吐量市场数据。大多数计算工作是通过multiprocessing 模块在单独的CPU 中完成的。这些并行进程由主进程在启动时产生。如果我希望通过QuickFix 以任何方式与市场互动，我必须在主进程中执行此操作，因此来自子进程的任何命令（例如输入订单）都必须通过管道传输（通过@ 987654328@ 对象我们将在执行前调用Q) 到主进程。

这引发了监控Q 的问题，这必须在主进程中完成。我不能使用Q.get()，因为此方法会阻塞，并且我的整个主进程将挂起，直到Q 中出现某些内容。为了减少延迟，我必须经常检查Q，大约每秒 50 次。我一直在使用apscheduler 来执行此操作，但我不断收到警告错误，指出错过了运行时。这些错误是一个严重的问题，因为它们使我无法轻松查看重要信息。

因此，我重构了我的应用程序以使用 MestreLion 发布的代码作为对 this question 的回答。这对我有用，因为它从主进程启动一个新线程，并且不打印错误消息。但是，我担心这会在未来造成严重的问题。

我知道 python 中的全局解释器锁（这就是我开始使用multiprocessing 模块的原因），但我不太了解它。由于我的应用程序的高频特性，我不知道Q监控线程和消耗大量传入消息的主进程是否会竞争资源并相互减慢。

我的问题：

1. 在这种情况下我可能会遇到麻烦吗？

2. 如果没有，我可以使用当前方法添加更多监控线程并且仍然可以吗？至少还有两件事我想高频监控。

谢谢。

Answer 1

您已链接的@MestreLion's solution 在您的情况下每秒创建 50 个线程。

你只需要一个线程来消费队列而不阻塞主进程的其余部分：

import threading

def consume(queue, sentinel=None):
    for item in iter(queue.get, sentinel):
        pass_to_quickfix(item)

threading.Thread(target=consume, args=[queue], daemon=True).start()

在这种情况下，GIL 可能对性能有影响，也可能无关紧要。测量它。

Answer 2

在不了解您的情况的情况下，很难说出具体的内容。您的问题表明，线程大部分时间都在通过get 等待，所以 GIL 不是问题。进程间通信可能会更早地导致问题。在那里，您可以考虑使用某种 TCP 套接字切换到另一个协议。然后，您可以使用select 而不是线程来编写更高效的调度程序，因为线程也很慢并且消耗资源。 select 是一个系统函数，它允许一次监控多个套接字连接，因此它可以根据连接数量进行非常高效的扩展，并且几乎不需要 CPU 资源进行监控。