Безопасность потоков в словаре Python

107

У меня есть класс, в котором есть словарь

class OrderBook:
    orders = {'Restaurant1': None,
              'Restaurant2': None,
              'Restaurant3': None,
              'Restaurant4': None}

    @staticmethod
    def addOrder(restaurant_name, orders):
        OrderBook.orders[restaurant_name] = orders

И я запускаю 4 потока (по одному для каждого ресторана), которые вызывают этот метод OrderBook.addOrder. Вот функция, выполняемая каждым потоком:

def addOrders(restaurant_name):

    #creates orders
    ...

    OrderBook.addOrder(restaurant_name, orders)

Это безопасно, или мне нужно использовать блокировку перед звонком addOrder?

nmat
источник
2
как может быть проблема, когда каждый поток все равно записывает на свой ключ.
Йохен Ритцель
65
@Jochen: в зависимости от того, как реализованы диктовки, многое может пойти не так. Это очень разумный вопрос.
Нед Батчелдер

Ответы:

97

Встроенные структуры Python являются потокобезопасными для отдельных операций, но иногда бывает трудно понять, где оператор действительно превращается в несколько операций.

Ваш код должен быть в безопасности. Имейте в виду: замок здесь почти не добавит накладных расходов и даст вам душевное спокойствие.

http://effbot.org/pyfaq/what-kinds-of-global-value-mutation-are-thread-safe.htm содержит более подробную информацию.

Нед Батчелдер
источник
6
Вот почему на effbot.org и инструкции по установке блокировки
hobs
1
Следует рассмотреть отдельные операции по сравнению с составными операциями, такими как get-add-set .
Энди
5
Проблема в том, что когда я часто читаю / пишу это изречение, душевное спокойствие будет мне дорого стоить.
Шихаб Шахриар Хан
2
«блокировка здесь почти не добавляет накладных расходов»: почему?
макс
32

Да, встроенные типы по своей сути являются потокобезопасными: http://docs.python.org/glossary.html#term-global-interpreter-lock

Это упрощает реализацию CPython, делая объектную модель ( включая критически важные встроенные типы, такие как dict ) неявно защищенной от одновременного доступа.


источник
25
Это особенность не Python, а cpython .
phihag 05
8
Верно, но, насколько я понимаю, встроенные в Jython и IronPython также потокобезопасны даже без использования GIL (и незагруженная ласточка, если она когда-либо появится, также предлагает покончить с GIL). Я предположил, что, поскольку он не указал используемый интерпретатор, он имел в виду CPython.
1
Правильно в случае Jython: jython.org/jythonbook/en/1.0/…
Евгений Сергеев
9

Руководство по стилю Google не рекомендует полагаться на атомарность диктовки

Более подробно объясняется в: Является ли присвоение переменной Python атомарным?

Не полагайтесь на атомарность встроенных типов.

Хотя встроенные в Python типы данных, такие как словари, по-видимому, имеют атомарные операции, есть угловые случаи, когда они не являются атомарными (например, если __hash__или __eq__реализованы как методы Python), и на их атомарность не следует полагаться. Вы также не должны полагаться на присвоение атомарной переменной (поскольку это, в свою очередь, зависит от словарей).

Используйте Queueтип данных Queue модуля как предпочтительный способ обмена данными между потоками. В противном случае используйте модуль потоковой передачи и его блокирующие примитивы. Узнайте о правильном использовании условных переменных, чтобы вы могли использовать их threading.Conditionвместо низкоуровневых блокировок.

И я согласен с этим: в CPython уже есть GIL, поэтому снижение производительности при использовании Lock будет незначительным. Гораздо дороже будут часы, потраченные на поиск ошибок в сложной кодовой базе, когда эти детали реализации CPython изменятся в один прекрасный день.

Чиро Сантилли 郝海东 冠状 病 六四 事件 法轮功
источник