是否可以优先考虑锁定? [英] Is it possible to prioritise a lock?

问题描述

我有一个multiprocessing程序，

• 一个进程将元素添加到共享列表(multiprocessing.Manager().list())
• 其他几个进程从列表中消耗这些元素(并删除它们)；它们会一直运行，直到列表中有需要处理的东西，并且上面的过程仍会添加到列表中.

在添加到列表或从列表中删除时，我实现了锁定(通过multiprocessing.Lock()).由于有一个馈送"进程和几个(10-40)个消费者"进程都在争夺锁，并且用户进程非常快，因此我最终遇到了馈送"进程，该进程很难获取锁.

I implemented locking (via multiprocessing.Lock()) when adding to the list, or removing from it. Since there is one "feeder" process and several (10-40) "consumer" ones all competing for the lock, and that the consumer processes are fast, I end up with the "feeder" process having a hard time acquiring the lock.

获取锁时是否存在优先级"概念?我希望馈线"过程比其他进程具有更高的优先级.

Is there a concept of "priority" when acquiring a lock? I would like the "feeder" process to acquire it with more priority than the others.

现在，我通过让消费者"进程等待一个随机时间，然后在馈线"进程在那里(当它结束时它设置了一个标志)来尝试获取锁，从而缓解了该问题.这是一个可行的解决方法，但是它很难而且几乎没有效果(我让进程等待random.random()*n秒，其中n是进程数.这是一个完全由数字组成的数字，可能是错误的).

Right now I mitigated the issue by having the "consumer" processes wait a random time before trying to acquire the lock while the "feeder" process is there (when it ends it sets a flag). This is a workaround which works but it is ugly and hardly effective (I have the processes wait random.random()*n seconds, where n is the number of processes. This is a completely made up number, probably wrong).

推荐答案

使Feeder获得锁定锁定，而使用者获得非锁定.
因此对于馈线:

Make the Feeder's acquisition of the lock blocking, and the consumer's non-blocking.
So for the feeder:

try:
    with my_lock.acquire(): #locks block by default
        do stuff
finally:
    my_lock.release()

还有消费者:

while True:
   try:
      locked = my_lock.acquire(blocking=False)
      if locked:
         do stuff
   finally:
      if locked:
         my_lock.release()
   time.sleep(seconds=10)

这篇关于是否可以优先考虑锁定?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！