У меня есть типичный сценарий, когда у меня есть конечное число потоков / рабочих, которые всегда извлекают и обрабатывают задачи из очереди. Эти задачи типичны для чтения> процесс> сохранить. Оказывается, некоторые из этих задач могут сами добавить в очередь задач и будут ждать выполнения поставляемой ими задачи до конца sh перед выпуском (типичная операция .join ()).
В этом сценарии мы вполне может зайти в тупик, когда конечное число работников распределено и занято задачами, которые сами ожидают завершения других задач - но без работников они никогда не делают, а мы заходим в тупик. Например, 5 рабочих доступны, они сразу же берут 5 задач, которые запускают еще 15 задач и ждут их завершения - они никогда не будут завершены, поскольку заблокированы только 5 доступных рабочих.
Очевидно, что при достаточном количестве рабочих это будет меньше шансов случиться, но это не очень удовлетворительно (вполне может быть, что 200 рабочих опрашивают по 20 новых задач каждый). Некоторый обходной путь, о котором я думал - но ни один из них не выглядит элегантным
- Я мог бы создать отдельную очередь / пул рабочих для тех вторичных задач, которые не зависят от других задач (или каждый работник создал свою собственную отдельную очередь / пул работника при необходимости)
- Я мог бы сделать задачи неблокирующими (частичное сохранение результатов в базу данных, при этом другие завершают результаты, но база данных в нестабильном состоянии не звучит хорошо)
Есть идеи по поводу правильного дизайна для этого сценария?