Так зачем же нам изучать еще одну парадигму параллельной обработки и еще один инструмент, когда у нас уже имеются потоки выполнения, процессы, инструменты IPC, такие как сокеты, каналы и очереди, изучавшиеся выше? Прежде чем погружаться в детали, мне хотелось бы сказать несколько слов о том, зачем вам может (или не может) потребоваться этот пакет. Несмотря на то, что по своей производительности этот пакет не может конкурировать с низкоуровневыми механизмами потоков выполнения и порождения процессов, во многих случаях он может оказаться весьма привлекательным решением:
• В отличие от приема ветвления процессов, этот пакет обеспечивает высокую степень переносимости и предоставляет мощные инструменты IPC.
• В отличие от механизма потоков выполнения, этот пакет обеспечивает по-настоящему параллельное выполнение задач в многопроцессорных системах, хотя и за счет некоторой потери времени, необходимого на выполнение процедуры запуска.
С другой стороны, этот пакет накладывает некоторые ограничения, отсутствующие в механизме потоков выполнения:
• Так как объекты приходится копировать через границы процессов, они не могут располагаться в совместно используемой памяти, как в случае потоков выполнения, — изменения в одном процессе не могут быть замечены в другом процессе. На практике возможность совместного использования памяти может оказаться самой веской причиной использования потоков выполнения, а отсутствие такой возможности в этом пакете может ограничить круг его применения в определенных контекстах.
• Так как этот пакет требует, чтобы процессы в Windows, а также некоторые инструменты IPC поддерживали возможность сериализации, это может усложнить или сделать непереносимой реализацию некоторых парадигм программирования, особенно когда в них предусматривается использование связанных методов или передача несериализуемых объектов, таких как сокеты, в порожденные процессы.
Например, типичный прием использования lambda-функций, который прекрасно работает при использовании модуля threading, не может использоваться для передачи вызываемых объектов процессам в Windows, потому что они не могут быть сериализованы. Аналогично из-за невозможности сериализовать связанные методы объектов в многопоточных программах может потребоваться применять обходные решения, если потоки выполняют связанные методы или завершение потоков реализовано как передача им вызываемых объектов (возможно, даже связанных методов) через общие очереди. Модель потоков, выполняющихся в пределах одного и того же процесса, поддерживает возможность непосредственного использования lambda-функций и связанных методов, но модель отдельных процессов, реализованная в пакете multiprocessing, такой возможности не поддерживает.
В главе 10 мы напишем механизм управления потоками для графических интерфейсов, который опирается на возможность передачи вызываемых объектов через очередь в реализации операций завершения потоков, — вызываемые объекты помещаются в очередь рабочими потоками выполнения, извлекаются и переправляются дальше главным потоком. Многопоточная программа PyMailGUI, которая будет реализована в главе 14, использует этот механизм управления потоками для передачи через очередь связанных методов, реализующих операции завершения потоков, и выполнения этих методов в главном потоке. Эту схему невозможно непосредственно перенести на модель отдельных процессов, реализованную в пакете multiprocessing.
Не углубляясь в детали, отмечу: чтобы задействовать пакет multiprocessing в приложении PyMailGUI, операции в нем пришлось бы реализовать в виде простых функций или в виде подклассов процессов, чтобы обеспечить возможность сериализации. Хуже того, эти операции может потребоваться реализовать в виде простых идентификаторов, передаваемых через главный процесс, если они обновляют графический интерфейс или изменяют состояние объекта в целом, — сериализация приводит к созданию копии объекта в принимающем процессе и не является ссылкой на оригинал, а операция ветвления в Unix вообще копирует процесс целиком. Модификация изменяемого объекта, полученного из сериализованной копии в новом процессе, например, не окажет никакого влияния на оригинал.
Требование поддержки сериализации для аргументов процессов в Windows может ограничить область применения пакета multiprocessing и в других контекстах. Например, в главе 12 мы увидим, что этот пакет не может напрямую использоваться для решения проблемы непереносимости функции os.fork при традиционном подходе к разработке сетевых серверов в Windows, потому что подключенные сокеты некорректно сериализуются при передаче новому процессу, созданному этим пакетом, и не могут использоваться для общения с клиентом. В этом контексте потоки выполнения обеспечивают более переносимое и, пожалуй, более эффективное решение.
Ситуация с приложениями, которые обмениваются простыми сообщениями, обстоит намного лучше. Ограничения, касающиеся сообщений, проще преодолеть, особенно если эти сообщения составляют часть архитектуры приложения, изначально основанной на применении процессов. Кроме того, в этом пакете имеются другие инструменты, такие как менеджеры и API разделяемой памяти, которые, хотя и являются узкоспециализированными и не такими универсальными, как память, совместно используемая потоками выполнения, тем не менее способны в некоторых случаях предоставить дополнительные возможности обмена информацией между процессами.
Однако в целом, благодаря тому что пакет multiprocessing опирается на использование отдельных процессов, он лучше подходит для реализации относительно независимых задач, которым не требуется общая память и для нормальной работы вполне достаточно возможности обмена сообщениями и инструментов доступа к разделяемой памяти, имеющихся в этом пакете. К их числу можно отнести множество приложений, но это не означает, что с помощью данного пакета можно напрямую заменить любые многопоточные программы, и он не во всех случаях может быть альтернативой приему, основанному на ветвлении процессов.
Чтобы по-настоящему оценить преимущества и слабые стороны этого пакета, обратимся к первому примеру и попутно исследуем реализацию пакета.
Использованная литература:
Марк Лутц — Программирование на Python, 4-е издание, I том, 2011
