Задача проектирования: объединение объектов, отправленных в обработчик - PullRequest
0 голосов
/ 03 февраля 2011

Я ищу совет или критику концепции дизайна для объединения объектов Runnable, опубликованных в обработчике.Дело в том, что у меня есть фоновый поток, который генерирует небольшие куски работы, которые должны быть выполнены в потоке событий.Каждый кусок публикуется в обработчике как Runnable обычным способом.Оказывается, что если один из этих Runnables еще не начал выполняться, было бы легко изменить его для выполнения дополнительной работы, когда он все-таки выполняется, вместо создания и публикации другого Runnable.Такое объединение рабочих блоков будет дешевле, чем создание другого Runnable, а также уменьшит проблему фонового потока, затопляющего очередь событий.

Однако есть пара проблем.Во-первых, мне нужно иметь доступ к последнему Runnable, доставленному в очередь событий.Насколько я знаю, ни Handler, ни Looper не предлагают никакой подобной функции, поэтому я планировал просто сохранить ссылку на последний опубликованный Runnable в своем коде фонового потока.Я просто предполагаю, что поддержание такой ссылки не вызовет проблем нигде в системе.

Более серьезная проблема заключается в том, что мне нужно было бы каким-то образом узнать, был ли Runnableсняли с очереди и начали.Я планирую справиться с этим, добавив флаг в мой класс Runnable и установив его в начале метода run ().Все еще будет некоторая синхронизация, необходимая, чтобы избежать состояния гонки между проверкой флага и обновлением Runnable (фоновый поток) и установкой флага, как только Runnable начнет выполняться (поток событий).и если да, то как ты это сделал?Я пропускаю что-то, с чем мне нужно иметь дело?

1 Ответ

1 голос
/ 03 февраля 2011

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

Если вы действительно хотите пойти с этим (я, возможно, не совсем понимаю вашу ситуацию), не будет ли легче иметь некоторый пул «рабочих блоков», где будет храниться вся необходимая работа и какая-то работа стартер, который запускает новый Runnable время от времени. Это выглядит так:

С первым событием «рабочий стартер» отправляет работающий обработчик. Этот исполняемый модуль просит пул предоставить ему всю доступную в настоящее время работу и обрабатывает ее, в конце он сообщает «стартеру работы», что он завершен, стартер запускает другой работающий модуль, который запрашивает пул для новой работы и т. Д. Размещаемый вами исполняемый файл может быть подклассом вашего собственного работающего рабочего, чтобы упростить эти запросы в пул и сообщить о выполненной работе. Не нужно хранить флаги или менять runnables. И не нужно иметь дело с проблемами параллелизма (если у вас есть только один обработчик)

...