Пул рабочих, в котором определенные задачи могут выполняться только определенными работниками

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

Кажется, что для этого должен быть шаблон параллелизма, но я не могу его найти. Я реализую это в Python 2 с многопроцессорной обработкой, поэтому ответы в этих терминах были бы замечательными, но универсальное решение подойдет. В моем случае «потоки» на самом деле являются отдельными процессами ОС, а ресурсы — сетевыми подключениями (и нет, это не сервер, поэтому (e) опрос/выбор не поможет). Как правило, поток/процесс может содержать несколько ресурсов.

Вот наивное решение: поместить задачи в рабочую очередь и освободить для нее мой пул потоков. Пусть каждый поток проверяет: «Могу ли я выполнить эту задачу?» Если да, сделайте это; если нет, верните его в очередь. Однако, если каждая задача может быть выполнена только одним из N потоков, то я делаю около 2N дорогих, бесполезных обращений к общей очереди только для того, чтобы получить одну единицу работы.

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

Идеи?


person Doctor J    schedule 16.06.2012    source источник
comment
Я позволил себе изменить название; как вы говорите, ваши потоки на самом деле не являются потоками, поэтому кажется подходящим что-то более общее. Решения могут быть по существу одинаковыми для потоков и процессов, но есть мысленный скачок скорости (по крайней мере, у меня был), когда я задаю вопрос о потоках, а затем обнаруживаю, что дело не в потоках. Возможно, вы захотите немного переформулировать вопрос, чтобы сделать его еще более гладким.   -  person Tom Anderson    schedule 17.06.2012
comment
Я думаю, что ваша идея очереди для каждого ресурса хороша. Обработчикам нужно будет проверять несколько очередей, а это значит, что они не могут использовать блокирующие чтения и должны иметь порядок приоритетов для этих очередей (на самом деле, ресурсов).   -  person Tom Anderson    schedule 17.06.2012


Ответы (1)


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

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

Можно использовать массив semaphore+concurrentQueue, проиндексированный по ресурсу, для сигнализации таких потоков, а также для обеспечения системы приоритетов, что устраняет большую часть опроса и расточительного повторного постановки в очередь. Мне придется немного подумать об этом - это зависит от того, как ресурсы сопоставляются с потоками.

person Martin James    schedule 16.06.2012