Доступ к железу в многопоточном приложении Опции

[r_13]

Добрый день,
есть многомодульная программа с кучей потоков (threads) и есть железо, которое подключается по USB. Один из модулей ловит сообщения от USB и создает\удаляет объекты класса Device, который предоставляет доступ к железу. Куча других классов из разных модулей получает указатели на объекты этого класса по запросу и манипулируют с ними. Если происходит USB disconnect, то модуль, что раздает указатели на Device, посылает соответствующее сообщение. Но поскольку система многопоточная, то сообщение может прийти позже, чем будет попытка обращения к недоступному более железу.
Ясно, что надо синхронизировать через mutex (что и делается), но количество объектов, желающих общаться с железом растет и учесть все варианты становится все сложнее. Может есть какой-нибудь design pattern для этого? Может это не правильно раздавать всем подряд указатели? Нужен какой-нибудь режим регистрации тех, кто получает указатель? Задача то довольно стандартная для околожелезячных прог. Наверняка есть "стандартное" решение\подход...

[Влад]

r_13, мне вот как раз несколько (эххх.... изрядно уж!) лет назад приходилось разрабатывать похожую систему..... Несколько (много) "железных" устройств общались с компами по COM-портам и еще взаимодействовали друг с другом при этом.
Архитектура получилась следующая:
- на каждый тип "железного" устройства конструируется свой класс. Все эти "железячные" классы наследуют и поддерживают единый общий интерфейс (наследуются от абстрактного класса). Внутри класса для общения с устройством через COM-порт создаются два потока: на прием и на передачу, и две очереди: принятых сообщений и сообщений на отправку. Класс сам отслеживает таймауты, состояние устройства и прочее....
- количество экземпляров нужного класса определяется количеством железок данного типа, подключенных по каналам связи (у меня читалось из конфиг файла).
- для организации взаимодействия устройств друг с другом сконструирован еще один класс - условно, диспетчер. Диспетчер создает (читая из конфига) нужное число экземпляров конкретных классов.
- взаимодействие экземпляров между собой (как экземпляров одного класса, так и разных классов) идет по схеме "поставщик сообщений - подписчики". Все сообщения, принятые от конкретной железки, экземпляр соответствующего класса отдает диспетчеру. А диспетчер ведет реестр (список, лист) подписчиков, и отдает им сообщения. Здесь получается топология типа "звезда". Подписчик указывает, сообщения какого типа (а они разных типов) он желает получать. Каждый подписчик сам решает, как обрабатывать полученные сообщения. Прямого взаимодействия между железячными экземплярами нет, все идет только и исключительно через диспетчер.
- в одном компе - один диспетчер и несколько "железячных" экземпляров. А диспетчеры разных компов общаются по Ethernet по такой же схеме - на одном компе поднимается "сервер", по сути дела - диспетчер более высокого уровня. Здесь тоже топология "звезда".
Вот как-то так.....

Сообщение отредактировал Влад - 18.1.2012, 9:29