Как глубоко вложенные потоки управляются в многопоточной архитектуре - PullRequest
0 голосов
/ 06 февраля 2019

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

Вопрос в том, нужен ли вам глобальный / центральный менеджер для всех этих потоков, или это можно / нужно сделать по-другому.

Итак, выесть что-то вроде:

|------------ 1
    |________ 1.1
    |   |____ 1.1.1
    |   |____ 1.1.2
    |   |____ 1.1.3
    |   |____ 1.1.4
    |   |____ 1.1.5
    |
    |________ 1.2
    |   |____ 1.2.1
    |   |____ 1.2.2
    |   |____ 1.2.3
    |   |____ 1.2.4
    |   |____ 1.2.5
    |
    |________ 1.3
    |   |____ 1.3.1
    |   |____ 1.3.2
    |   |____ 1.3.3
    |   |____ 1.3.4
    |   |____ 1.3.5
    |
    | ...
    |________ 1.5
        |____ 1.5.1
         ...

Так что на этой диаграмме около 31 процесса, но если вы добавите еще один слой из 5 вложенных, вы получите намного больше.

Что мне интересно, так этообычно , кто управляет процессами.Кажется, что вы могли бы иметь несколько разных способов.С одной стороны, вы могли бы 1 «основной» процесс верхнего уровня, управляющий всеми вложенными и глубоко вложенными дочерними процессами.Это будет означать, что для всех процессов существует один «глобальный» уровень менеджера.Похоже, это облегчит планирование / установление приоритетов того, какой процесс получает доступ к ресурсам, потому что есть центральный менеджер.В то же время, однако, ему не хватает модульности, и он не действует как многопроцессный процесс реального мира.

Но, возможно, вы могли бы сделать это по-другому.Вы можете иметь каждый родительский узел только управлять своими прямыми потомками.Это имеет смысл с точки зрения чистоты, поскольку каждый процесс будет отвечать только за управление своими дочерними элементами.Это своего рода иерархически управляемые организации / предприятия.Но я быстро запутываюсь, думая, как бы вы справились с проблемами планирования в последовательной архитектуре.Я никогда не реализовывал это, поэтому я не уверен, насколько это сложно, но сначала это кажется сложным.Вы могли бы столкнуться с ситуацией, когда 1.3.5 использовал кучу ресурсов, но 1.1.1 действительно нужно было выполнить некоторую обработку, а 1.2 на высоком уровне тоже хотел выполнить некоторую работу.Таким образом, некоторый центральный менеджер (кажется, должен) координирует передачу сообщений между этими процессами, чтобы помочь им согласовывать график друг с другом.Но затем мы вернулись к первой ситуации глобального центрального менеджера.Поэтому я не знаю, как этого избежать.

Третий подход может заключаться в том, где каждый процесс управляет собой.У них есть центральная разновидность «реестра», где они могут отмечать свой прогресс, и все они действуют определенным образом в отношении этого «контракта».Таким образом, на самом деле не столько центральный менеджер, сколько децентрализованная сеть.Но это также быстро усложняется, когда вы пытаетесь представить, как вы будете разрешать сложные цепочки / графики конфликтов во время планирования и расстановки приоритетов.Я поражен этим.

Так что мне интересно, каков общий подход к этой проблеме.Если это (1) глобальный центральный менеджер, (2) родительское / дочернее управление или (3) децентрализованный реестр / самоуправление, или (4) другая вещь помимо этих подходов.Зная это, станет понятнее, как реализовать несколько потоков в последовательной архитектуре, такой как в JavaScript, для обучения.Вы должны выполнить 1, 2 или 3, и у вас могут быть потоки, каждый из которых получает возможность выполнить обработку.Я просто не могу сказать, требуется ли для этого центральный менеджер или нет, поэтому мне интересно, что типичный подход в надежной системе и каков подход best / грубо говоря.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...