【问题标题】:Status of mixing multiprocessing and threading in PythonPython中混合多处理和线程的现状
【发布时间】:2012-10-10 15:27:03
【问题描述】:

对于问题 6721,在 Linux 中的同一 python 应用程序中使用多处理和用户线程的最佳做法或解决方法是什么,python 标准库中的锁应该在 fork 上进行清理?

为什么我需要两者?我使用子进程进行繁重的计算,产生的数据结构结果太大而无法通过队列返回——而是必须立即将它们存储到磁盘。让这些子进程中的每一个由一个单独的线程监控似乎很有效,这样当完成时,线程可以处理将大(例如,多 GB)数据读回需要结果以进行进一步计算的进程的 IO结合其他子进程的结果。 子进程会间歇性地挂起,我刚刚(经过多次头部撞击)发现这是使用日志模块“引起”的。其他人在这里记录了这个问题:

https://twiki.cern.ch/twiki/bin/view/Main/PythonLoggingThreadingMultiprocessingIntermixedStudy

这指向了这个显然未解决的 python 问题:python 标准库中的锁应该在 fork 上进行清理; http://bugs.python.org/issue6721

我对追踪这件事的困难感到震惊,我回答:

Are there any reasons not to mix Multiprocessing and Threading module in Python

带有对“小心”的相当无益的建议和指向上述内容的链接。

但是关于:Issue 6721 的冗长讨论表明,在同一应用程序中同时使用多处理(或 os.fork)和用户线程是一个“错误”。由于我对这个问题的理解有限,我在讨论中发现太多分歧,无法得出在同一应用程序中同时使用多处理和线程的解决方法或策略是什么。我的直接问题通过禁用日志记录得到解决,但我在父进程和子进程中创建了少量其他(显式)锁,并且怀疑我正在为进一步的间歇性死锁设置自己。

在 python (2.7,3.2,3.3) 应用程序中使用线程和多处理时,您能否给出实用的建议来避免在使用锁和/或日志记录模块时出现死锁?

【问题讨论】:

  • 有趣的是multiprocessing 模块已经在内部使用treading 模块来创建一些分叉感知类型(包括锁类型)。见util.py。这些类型用于来自manager.pyBaseProxy 类。

标签: python multithreading logging multiprocessing locks


【解决方案1】:

如果您在程序中仍然只有一个线程(即,在产生工作线程之前从主线程分叉)时分叉其他进程,您将是安全的。

您的用例看起来甚至不需要多处理模块;您可以使用子进程(甚至更简单的类似 os.system 的调用)。

另见Is it safe to fork from within a thread?

【讨论】:

  • this answer 与问题特别相关
  • 这是一篇非常有用的前一篇文章,谢谢。我知道我不需要多处理模块,但它确实提供了一个我使用的队列(只是不用于最终结果)。
  • Re: 用一个线程分叉。好建议。在这里,我正在遍历一个未知的依赖关系图,所以它有点棘手,但我确实很早就在单独的进程中创建了一个服务器,它监控请求队列并启动新进程。这适用于我控制继承状态的独立应用程序,但作为库,我必须处理该状态。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-02-08
  • 1970-01-01
  • 1970-01-01
  • 2015-02-11
  • 1970-01-01
  • 1970-01-01
  • 2013-04-03
相关资源
最近更新 更多