Глава 2. Вся правда о потоках

Вот самые главные преимущества применения потоков:

Теперь, что касается Python, этот момент достаточно спорный, поскольку интерпретатор Python применяет некую глобальную блокировку, называемую Global Interpreter Lock, для защиты своего внутреннего состояния интерпретатора самого по себе - защита от возможного катастрофического эффекта конкуренции между множеством потоков. Неким побочным эффектом такой блокировки является то, что заканчивается пришпиливанием всех потоков из вашей программы к некому единственному ЦПУ. Как вы можете себе представить, это отвергает любые преимущества одновременной производительности (только если вы не используете такие инструменты как Cython или Numba для манёвра вокруг данного ограничения).

Тем не менее, самый первый пункт в отношении простоты является существенным: потоки в Python кажутся чрезвычайно простыми и, если вы не сгорите в огне невероятно жёстких ошибок конкуренции, работа с потоками предлагает очень привлекательную модель параллелизма. И даже если вы были сожжены в прошлом, работа с потоками остаётся неотразимым вариантом, так как скорее всего, вы прошли обучение (это трудный путь) как одновременно сохранять свой код простым и безопасным.

У меня нет достаточного пространства входить в детали безопасного программирования здесь, однако говоря в целом, наилучшей практикой применения потоков является применение класса ThreadPoolExecutor() из имеющегося модуля concurrent.future, передавая все необходимые данные через его метод submit().

Вот некий базовый пример:

from concurrent.future import ThreadPoolExecutor as Executor

def worker(data):
    <process the data>

with Executor(max_workers=10) as exe:
    future = exe.submit(worker, data)
 	   

Этот ThreadPoolExecutor предлагает чрезвычайно простой интерфейс для запуска функций в потоках - и самая лучшая часть состоит в том, если необходимо, что вы можете конвертировать имеющийся пул потоков в некий пул сопроцессов просто применяя вместо этого ProcessPoolExecutor. Он имеет тот же самый API, что и ThreadPoolExecutor, что означает что ваш код будет подвергнут небольшому воздействию данным изменением. Данный исполнитель API также применяется в asyncio и будет разъяснён в одном из последующих разделов.

В целом вы бы предпочли чтобы ваши задачи были чем- то с коротким временем жизни, с тем, чтобы когда вашей программе понадобится останов, вы могли бы просто вызвать Executor.shutdown(wait=True) и подождать секунду или две чтобы позволить данному исполнителю завершиться.

Что более важно: постарайтесь предотвратить в вашем коде потока (в приведённом выше примере, в функции worker()), доступ или запись в каких бы то ни было глобальных переменных!

Некоторые великолепные руководящие правила для более безопасного кодирования потоков были представлены Рэймондом Хеттингером на PyCon Russia 2016 и снова на PyBay 2017 и я настоятельно подгоняю вас добавить эти видео в ваш перечень просмотров.

... нетривиальные многопоточные программы непонятны людям. Это верно, что имеющуюся модель программирования можно улучшить путём применения шаблонов проектирования, лучшей детализации атомарности (например, транзакций), улучшенных языков программирования и методов формализации. Однако, эти техники просто отсекаются при имеющемся ненужном огромном недетерминизме существующей модели потоков. Данная модель остаётся в сущности не поддающейся решению. [2].

-- Эдвард А Ли, Основная проблема потоков - Technical Report No. UCB/EECS­2006­1 Electrical Engineering and Computer Sciences ­ University of California at Berkeley

Это не является новым, и мы уже упоминали об этом в некоторых иных местах, однако для завершённости давайте соберём им в кучку, тем не менее:

Ни одно из этих сведений не является новым, а все проблемы с потоками в виде модели программирования не являются даже особенными для платформы. Например, именно это говорит документация по руководству программированию MSDN Windows относительно построения потоков:

Самыми стержневым механизмом распараллеливания в существующем API Windows являются именно потоки. Обычно для создания потоков вы применяете функцию CreateThread. Хотя потоки относительно просты для создания и применения, сама операционная система уделяет значительное время и прочие ресурсы для управления ими. Кроме того, хотя каждому потоку гарантируется получение точно такого же времени исполнения что и для для остальных потоков с с тем же самым уровнем приоритета, а связанные с ними накладные расходы требуют того, чтобы создавала достаточно большие задачи. Для задач меньшего размера или с большей степенью детализации, те накладные расходы, которые связаны с распараллеливанием, могут перевешивать те преимущества, которые получают одновременно исполняемые задачи. [6].

-- Руководство программирования MSDN, Сопоставление Распараллеливание времени исполнения с прочими моделями одновременного исполнения

Но я слышу ваши протесты - это Windows, так? Несомненно, система Unix не имеет этих проблем? Вот приводим аналогичные рекомендации от Разработчиков библиотеки Mac:

Потоки имеют действительную стоимость для ваших программ (и всей системы) в терминах использования памяти и производительности. Каждый поток требует соответствующего выделения памяти как в пространстве самого ядра, так и в пространстве памяти вашей программы. Имеющиеся структуры ядра требуют управления вашим потоком и координации их планирования запоминаются в самом ядре при помощи зашитой памяти. Ваши пространство стека потока и данных каждого потока сохраняются в пространстве памяти вашей программы. Большая часть этих структур создаются и инициализируются при создании самом первом вашего потока - некого процесса, который может быть относительно затратным, так как он требует взаимодействия с сами ядром [7].

-- Библиотека разработчиков Mac, Руководство по программированию потоков

В своём Руководстве по параллельному программированию (выделено мною) они идут ещё дальше:

В прошлом введение распараллеливания в некое приложение требует определённого создания одного или более дополнительных потоков. К сожалению, написание кода с потоками является сложным. Потоки являются неким инструментом нижнего уровня, который должен управляться вручную. Принимая во внимание, что оптимальное число потоков для некоторого приложения может изменяться динамически на основе текущей загруженности системы и лежащего в её основе оборудования, реализация правильного решения с потоками становится чрезвычайно сложным, если даже невозможным для достижения. Кроме того, имеющиеся механизмы синхронизации обычно используются при добавлении сложности и рисков разработки потоков без каких бы то ни было гарантий улучшения производительности.[8].

-- Библиотека разработчиков Mac, Руководство по программированию потоков

Вот темы, которые постоянно повторяются:

Следующим мы рассмотрим некий пример вовлечения потоков в котором я попытаюсь высветить самый первый и самый важный момент.

Второе, и даже ещё более важное, мы не верили (и продолжаем сомневаться в ней) в стандартную модель со множеством потоков, которая является распараллеливанием с приоритетами при помощи совместно используемой памяти: мы всё ещё полагаем, что никто не может писать правильные программы на некотором языке программирования, в котором "a - a + 1" не детерминировано.[9].

-- Роберту Иерузалимски, Луиш Энрике ди Фигейреду, Валдемар Селиш, Эволюция Lua

В самом начале этой книге мы прослушали историю о ресторане, в котором роботы- гуманоиды - Серийные боты - выполняют всю работу. В соответствии с этой аналогией всякий исполнитель (worker) является каким- то потоком. В данном примере мы собираемся рассмотреть почему потоки рассматриваются как не безопасные.

import threading
from queue import Queue

class ThreadBot(threading.Thread):()
  def __init__(self):
    super().__init__(target=self.manage_table)()
    self.cutlery = Cutlery(knives=0, forks=0)()
    self.tasks = Queue()()

  def manage_table(self):
    while True:()
    task = self.tasks.get()
    if task == 'prepare table':
      kitchen.give(to=self.cutlery, knives=4, forks=4)()
    elif task == 'clear table':
      self.cutlery.give(to=kitchen, knives=4, forks=4)
    elif task == 'shutdown':
      return
 	   

А теперь определим объект Столового прибора:

from attr import attrs, attrib

@attrs()
class Cutlery:
    knives = attrib(default=0)()
    forks = attrib(default=0)
	
    def give(self, to: 'Cutlery', knives=0, forks=0):()
    self.change(­knives, ­forks)
    to.change(knives, forks)

    def change(self, knives, forks):()
            self.knives += knives
            self.forks += forks

kitchen = Cutlery(knives=100, forks=100)()
bots = [ThreadBot() for i in range(10)]()

import sys
for bot in bots:
    for i in range(int(sys.argv[1])):()
        bot.tasks.put('prepare table')
        bot.tasks.put('clear table')
    bot.tasks.put('shutdown')()

print('Kitchen inventory before service:', kitchen)
for bot in bots:
    bot.start()

for bot in bots:
    bot.join()
print('Kitchen inventory after service:', kitchen)
 	   

Ваша стратегия проверки созданного кода в основном вовлекает запуск некой группы Серийных ботов для последовательности обслуживания столов. Каждый серийный юот должен:

Если вы запускаете пачку Серийных ботов на некое множество столов определённое число раз, вы ожидаете, что после того как вся работа будет выполнена, все ножи и вилки должны оказаться вновь на кухне и пересчитаны.

Поступая с умом, вы решаете проверить это, причём при подготовке и уборке 100 столов для каждого из Серийных ботов, и при этом все они работают одновременно, поскольку вы желаете убедиться что они могут работать совместно и всё пройдет хорошо. Вот вывод данной проверки:

$ python cutlery_test.py 100
Kitchen inventory before service: Cutlery(knives=100, forks=100)
Kitchen inventory after service: Cutlery(knives=100, forks=100)
 	   

Все ваши ножи и вилки вернулись обратно на кухню! Поэтому вы поздравляете себя с хорошо написанным кодом и успешным развёртыванием ботов. К сожалению, на практике, вы то и дело обнаруживаете что вы не завершаете полным пересчётом столовых приборов при каждом закрытии своего ресторана. Вы замечаете, что данная проблема ухудшается когда вы добавляете дополнительных ботов и/ или места становятся более загруженными. Разочаровавшись, вы проводите свою проверку вновь, ничего не изменяя за исключением установления размера данной проверки (10 000 столов!):

$ python cutlery_test.py 10000
Kitchen inventory before service: Cutlery(knives=100, forks=100)
Kitchen inventory after service: Cutlery(knives=96, forks=108)
 	   

Оп- ля- ля! Теперь вы видите, что проблема имеется на самом деле. При 10 000 обслуженных столах вы заканчиваете с неверным числом ножей и вилок, остающихся на кухне. Для воспроизведения вы проверяете эту ошибку на повторяемость:

$ python cutlery_test.py 10000
Kitchen inventory before service: Cutlery(knives=100, forks=100)
Kitchen inventory after service: Cutlery(knives=112, forks=96)
 	   

Всё ещё остаются ошибки, но с с иными численными значениями в сравнении с предыдущим исполнением. Это просто смешно! Вы ведь знаете, что эти боты исключительно хорошо сконструированы и они не ошибаются. Что же могло пойти не так?

Давайте подведём итог:

Именно это является несколькими типичными признаками ошибки состязательности. Умудрённый читатель уже видел такие примеры, поэтому давайте сейчас это исследуем. Всё сводится к данному методу внутри нашего класса Cutlery:

def change(self, knives, forks):
    self.knives += knives
    self.forks += forks
 	   

Данное внутреннее суммирование, +=, реализуется внутренним образом (в рамках собственно кода C для самого интерпретатора Python) как несколько отдельных этапов:

Основная проблема при многозадачности с приоритетами состоит в том, что любой занятой поток, находящийся на шаг впереди, может быть прерван в любой момент времени, причём различные потоки могут иметь шанс выполняться на одном и том же этапе.

В таком случае, Серийный бот A может делать этап 1, затем планировщик ОС приостанавливает A и переключается на Серийного бота B, а B тоже считывает текущее значение self.knives, затем исполнение передаётся обратно A и его приращения записываются обратно в новый итог - но затем B продолжает с того места где он был приостановлен (после шага 1), и после этого выполняет приращение и записывает обратно свой новый итог, тем самым удаляя те изменения, которые сделаны A!

Предостережение

Если описание данной состязательности звучит сложно, имейте, пожалуйста, в виду, что это пример (условия конкуренции) просто один из самых простых их всех возможных случаев. Мы способны проверить весь свой код, и мы даже можем проводить проверку, которая воспроизводит нашу проблему по запросу. В нашем реальном мире, в крупных проектах, попробуйте представить себе насколько большие трудности могут появляться.

Данную проблему можно исправить помещая блокировку вокруг необходимых изменений совместно используемого состояния (допустим, мы добавили threading.Lock в свой класс Cutlery):

def change(self, knives, forks):
  with self.lock:
    self.knives += knives
    self.forks += forks
 	   

Однако это требует знания всех тех мест, вкоторых состояние будет совместно использоваться множеством потоков. Данный подход жизнеспособен когда вы контролируете весь исходный код, но он становится очень сложным когда применяется много библиотек сторонних производителей - которые скорее всего на Python, благодаря прекрасной экосистеме открытого исходного кода.

Заметим, что невозможно отследить данное условие состязательности рассматривая исключительно имеющийся исходный код. Это происходит потому, что такой исходный код не даёт никаких советов о том, где происходит переключение между потоками. В любом случае он будет бесполезен, так как ваша ОС может переключаться между потоками практически в любом месте.

Другим, намного лучшим, решением - и это пункт асинхронного программирования - заключается в том, что мы изменяем свой код чтобы мы применяли только одного Серийного бота и настраивали его на перемещение между всеми имеющимися столами по мере необходимости. Для нашего примера это означает, что значения ножей и вилок будут изменяться только одним потоком.

И что ещё лучше: в наших асинхронных программах мы удем способны видеть в точности где контекст будет переключаться между множеством конкурирующих сопрограмм, потому что имеющееся ключевое слово await, которое указывает такие места в явном виде. Я решил не показывать некую асинхронную версию здесь, потому как наша следующая глава собирается подробно пояснять как использовать asyncio. Однако, если вы испытываете неутолимое любопытство, имеется некий снабжённый комментариями пример в наших Дополнениях; который, скорее всего, имеет смысл рассматривать только после прочтения нашей следующей главы!