Как оптимально использовать многопоточность при многопоточности в python? - PullRequest
0 голосов
/ 09 июля 2020

Я создал класс процессора в Python, который должен выполнять несколько исполняемых файлов параллельно (или последовательно). Классы процессора и исполняемого файла могут выглядеть следующим образом:

Class Processor(object):
    executables: list() # list of Executable objects
    should_execute_in_parallel: bool
    attr1: object
    attr2: object

    def process():
        # Pre-processing
        # Execute all executables serailly/parallely based on self.should_execute_in_parallel
        # Post-processing
    

Class Executable(object):
    cmd: str  # command string to execute
    attr1: object
    attr2: object

Я создал класс Executor, который принимает исполняемый файл и выполняет его

class Executor(object):
    def __init__(self, executable):
        self.executable = executable
        # This is to demonstrate that Executor object is stateful
        self.executable_id = self._get_executable_id(self.executable)

    def execute():
        # Pre-processing (I/O bound, depends on self)
        # Launch separate process for self.executable & monitor (I/O during each monitoring phase)
        # Post-processing (I/O bound, depends on self)

Я хочу распараллелить Executor.execute ( ) в Processor.process (). Поскольку каждый вызов Executor.execute () порождает новый процесс Python, одновременная обработка на уровне процессора может быть излишней. Следовательно, я думаю об использовании нескольких потоков для каждого объекта Executor, который, в свою очередь, порождает новый процесс для соответствующего исполняемого файла и продолжает его отслеживать.

Примечание. Процесс, запускаемый Executor.execute (), требует для периодического мониторинга объекта Executor, для которого я использую сигнал тревоги python. Ввод-вывод происходит на каждом этапе мониторинга.

  1. Есть ли в python рекомендуемый / оптимальный способ сочетания многопоточности с многопроцессорностью (как указано выше)?
  2. Как пока Executor.execute () не привязан к процессору (за исключением порожденного процесса), могут ли быть какие-либо проблемы с GIL?
  3. Было бы проще добиться параллелизма, если бы объекты Executor не имели состояния?
  4. Есть ли лучший способ решить этот вариант использования?

Ответы [ 2 ]

1 голос
/ 09 июля 2020

Я думаю, вам будет гораздо приятнее использовать один процесс и один поток и модуль подпроцесса из python. Если весь ваш код порождает другие программы, просто делайте это неблокирующим образом.

0 голосов
/ 09 июля 2020

В ответ на ваши вопросы могу ли я предложить следующие ответы, надеясь, что они помогут!

1. Есть ли в python рекомендуемый / оптимальный способ сочетания многопоточности с многопроцессорностью (как указано выше)?

Если вы вызываете разные процессы в системе, подумайте об использовании подпроцесс , который, в свою очередь, может быть вызван из множества потоков, управляемых пулом потоков . Если вам действительно нужны процессы, независимые от GIL, которому вы подчиняетесь, подумайте о переходе на multiprocessing или посмотрите, следует ли вам использовать параллельный / распределенный планировщик задач, такой как Dask.

2. Пока Executor.execute () не привязан к ЦП (за исключением порожденного процесса), могут ли возникнуть проблемы с GIL? python интерпретатор, в котором вы работаете, что может быть достигнуто с помощью multiprocessing , как упоминалось выше. Насколько я понимаю, при запуске процесса вашей ОС из этого объекта текущие потоки, которые вы используете, будут по-прежнему взаимодействовать с GIL (я уверен, что кто-то может объяснить это лучше, чем я ...)

3. Было бы проще достичь здесь параллелизма, если бы объекты Executor не имели состояния?

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

4. Есть ли лучший способ решить этот вариант использования?

Интересно, интересен ли вам пакет concurrent.futures

Я очень надеюсь, что это помогает, несомненно, поскольку это ранний ответ для меня, я мог бы сделать уточнение своих объяснений.

Удачи!

...