Шаблоны/Принципы для ориентированных на многопотоковое исполнение очередей и программы “ведущего устройства/рабочего” в Java

Взгляните на java.util.concurrent в библиотеке Java.

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

Также может оказаться полезной книга Java Concurrency in Practice Брайана Гетца.

Во-первых, почему вы хотите удерживать предметы после того, как рабочий начал их делать? Обычно у вас будет очередь работы, и работник забирает элементы из этой очереди. Это также решит проблему «как я могу предотвратить получение работниками одного и того же элемента».

На ваши вопросы:

1) как заставить «потоки» выполнять работа "связаться с мастером говоря им, что их работа завершено, и теперь мастер может удалить работу из очереди

Мастер может слушать рабочих, используя шаблон слушатель / наблюдатель

2) как эффективно иметь мастера гарантия, что работа только когда-либо запланировано один раз. Например, скажем в этой очереди миллион элементов, и она хочет сказать работнику «иди, сделай это 100 вещей ". Что самое эффективное способ гарантировать, что когда это расписывает работу следующему работнику, это получает "следующие 100 вещей", а не "100 вещей, которые я уже запланировано »?

См. выше. Я бы позволил рабочим вытаскивать элементы из очереди.

3) выбор подходящих данных структура для очереди. Мое мышление вот что "темы, находящие работу делать "потенциально может найти то же самое работать надо делать больше одного раза, и они отправить сообщение мастеру, говоря "вот работа", и мастер понять, что работа уже была запланированы и, следовательно, должны игнорируйте сообщение. Я хочу убедиться что я выбираю правильную структуру данных так что это вычисление так же дешево насколько возможно.

Существуют реализации блокирующей очереди , начиная с Java 5

Не забывайте Jini и Javaspaces. То, что вы описываете, очень похоже на классический паттерн производитель / потребитель, которым выделяются космические архитектуры.

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

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

Если вы открыты для идеи Spring, ознакомьтесь с их проектом Spring Integration. Он дает вам весь шаблон очереди / пула потоков из коробки и позволяет вам сосредоточиться на бизнес-логике. Конфигурация сведена к минимуму с помощью @annotations.

кстати, Goetz очень хорош.

This doesn't sound like a master-worker problem, but a specialized client above a threadpool. Given that you have a lot of scavenging threads and not a lot of processing units, it may be worthwhile simply doing a scavaging pass and then a computing pass. By storing the work items in a Set, the uniqueness constraint will remove duplicates. The second pass can submit all of the work to an ExecutorService to perform the process in parallel.

A master-worker model generally assumes that the data provider has all of the work and supplies it to the master to manage. The master controls the work execution and deals with distributed computation, time-outs, failures, retries, etc. A fork-join abstraction is a recursive rather than iterative data provider. A map-reduce abstraction is a multi-step master-worker that is useful in certain scenarios.

A good example of master-worker is for trivially parallel problems, such as finding prime numbers. Another is a data load where each entry is independant (validate, transform, stage). The need to process a known working set, handle failures, etc. is what makes a master-worker model different than a thread-pool. This is why a master must be in control and pushes the work units out, whereas a threadpool allows workers to pull work from a shared queue.