Как создать службу "Spool" для класса в C #

Question

Я смотрю на C # программирование довольно скрабно для языка. Я хотел бы думать, что у меня есть хорошее понимание объектно-ориентированного программирования в целом, и что означает запуск нескольких потоков, на высоком уровне, но реальная реализация, как сказал scrub.

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

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

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

Answer 1

Я часто использую такую ​​модель в различных системах.Я определяю класс для агентов, скажем «AgentClass» и один для запросов, скажем «RequestClass».Агент имеет два абстрактных метода: submit (RequestClass * message) и signal ().Как правило, поток в агенте создает очередь производителя-потребителя и ожидает в нем экземпляров RequestClass, метод submit () ставит в очередь переданные экземпляры RequestClass в очередь.RequestClass обычно содержит перечисление «command», которое сообщает агенту, что нужно делать, вместе со всеми данными, необходимыми для выполнения запроса, и экземпляром агента «sender».Когда агент получает запрос, он включает перечисление, чтобы вызвать правильную функцию для выполнения запроса.Агент действует только на данные в RequestClass - результаты, сообщения об ошибках и т. Д. Помещаются в элементы данных RequestClass.Когда агент выполнил запрос (или потерпел неудачу и сгенерировал данные об ошибках), он может либо отправить () запрос обратно отправителю (т. Е. Запрос был выполнен асинхронно), либо вызвать функцию signal () отправителей,whch сигнализирует о событии, которое ожидал отправитель (т. е. запрос был выполнен синхронно).

Обычно при запуске я создаю фиксированное количество экземпляров RequestClass и сохраняю их в глобальной очереди пула «пул».Любой агент / поток / что-либо, кроме того, что необходимо для отправки запроса, может удалить из очереди экземпляр RequestClass, заполнить данные, передать их () агенту, а затем асинхронно или синхронно ожидать выполнения запроса.Когда это сделано, RequestClass возвращается в пул.Я делаю это, чтобы избежать непрерывного malloc / free / new / dispose, облегчить отладку (я сбрасываю уровень пула в строку состояния с помощью таймера, поэтому я всегда замечаю, утечка или двойной запрос освобождается), и для устранениянеобходимость явного завершения потока при закрытии приложения (если несколько потоков только когда-либо читают / записывают данные в области данных, которые переживают формы приложения и т. д., приложение легко закрывается, и ОС может обрабатывать все потоки - существуют сотни сообщений о«Чистое завершение потоков при закрытии приложения» - я никогда не беспокоюсь!).

Такие конструкции передачи сообщений довольно устойчивы к взаимоблокировкам, поскольку единственные блокировки (если они есть) находятся в очередях ПК, хотя выможет, конечно, добиться этого, если вы попытаетесь достаточно усердно:)

Это та система, которая вам нужна, или я ошибся?

Rgds, Martin