这个Python生产者 – 消费者无锁方法是否是线程安全的?

前端之家收集整理的这篇文章主要介绍了这个Python生产者 – 消费者无锁方法是否是线程安全的?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我最近编写了一个使用简单生产者/消费者模式的程序.它最初有一个与不正确使用线程有关的错误.我最终解决了这个问题.但它让我想到是否有可能以无锁的方式实现生产者/消费者模式.

我的要求很简单:

>一个生产者线程.
>一个消费者线程.
>队列只有一个项目.
>生产者可以在消耗当前物品之前生成下一个物品.因此当前项目丢失了,但这对我来说没问题.
>消费者可以在生成下一个项目之前使用当前项目.因此,当前项目被消耗两次(或更多),但这对我来说没问题.

所以我写了这个:

QUEUE_ITEM = None

# this is executed in one threading.Thread object
def producer():
    global QUEUE_ITEM
    while True:
        i = produce_item()
        QUEUE_ITEM = i

# this is executed in another threading.Thread object
def consumer():
    global QUEUE_ITEM
    while True:
        i = QUEUE_ITEM
        consume_item(i)

我的问题是:这段代码是否是线程安全的?

直接评论:这段代码不是真的无锁 – 我使用CPython并且它有GIL.

我测试了一点代码,它似乎工作.它转换为一些由于GIL而成为原子的LOAD和STORE操作.但我也知道,当x实现__del__方法时,del x操作不是原子操作.因此,如果我的项目有__del__方法并且发生了一些讨厌的调度,那么事情可能会中断.或不?

另一个问题是:为了使上述代码正常工作,我必须施加什么样的限制(例如生成的项目类型)?

我的问题只是关于利用CPython和GIL的怪癖的理论可能性,以便提出无锁(即没有像代码中的threadading.Lock那样的锁)解决方案.

解决方法

是的,这将按照您描述的方式工作:

>生产者可以生产可跳过的元素.
>消费者可能消费相同的元素.

But I also know that del x operation isn’t atomic when x implements del method. So if my item has a del method and some nasty scheduling happens,things may break.

我在这里看不到“del”.如果在consume_item中发生del,则del可能出现在生成器线程中.我不认为这会是一个“问题”.

尽管不要打扰使用它.您将最终在无意义的轮询周期中耗尽cpu,并且它不会比使用带锁的队列更快,因为Python已经具有全局锁定.

猜你在找的Python相关文章