Доступ к железу в многопоточном приложении |
Здравствуйте, гость ( Вход | Регистрация )
Доступ к железу в многопоточном приложении |
r_13 |
17.1.2012, 14:10
Сообщение
#1
|
Новичок Группа: Новичок Сообщений: 3 Регистрация: 13.9.2011 Пользователь №: 2870 Спасибо сказали: 0 раз(а) Репутация: 0 |
Добрый день,
есть многомодульная программа с кучей потоков (threads) и есть железо, которое подключается по USB. Один из модулей ловит сообщения от USB и создает\удаляет объекты класса Device, который предоставляет доступ к железу. Куча других классов из разных модулей получает указатели на объекты этого класса по запросу и манипулируют с ними. Если происходит USB disconnect, то модуль, что раздает указатели на Device, посылает соответствующее сообщение. Но поскольку система многопоточная, то сообщение может прийти позже, чем будет попытка обращения к недоступному более железу. Ясно, что надо синхронизировать через mutex (что и делается), но количество объектов, желающих общаться с железом растет и учесть все варианты становится все сложнее. Может есть какой-нибудь design pattern для этого? Может это не правильно раздавать всем подряд указатели? Нужен какой-нибудь режим регистрации тех, кто получает указатель? Задача то довольно стандартная для околожелезячных прог. Наверняка есть "стандартное" решение\подход... |
|
|
Влад |
17.1.2012, 14:29
Сообщение
#2
|
Участник Группа: Участник Сообщений: 146 Регистрация: 20.3.2009 Из: Санкт-Петербург Пользователь №: 627 Спасибо сказали: 46 раз(а) Репутация: 8 |
Мне кажется, что это неправильно, что один модуль раздает другим указатели, и эти другие - делают, что хотят и когда хотят..... в том числе, могут обращаться к недоступному больше железу.
Лично я бы сделал бы несколько иначе а врхитектурном плане: Один модуль ловит сообщения от USB _и_ общается с железом. Он предоставляет всем остальным модулям доступ к железу посредством доступа к _своему интерфейсу_, не предоставляя этим "остальным модулям" прямого доступа к железу. Запросы сторонних модулей могут ставиться в очередь и обрабатываться по логике, определяемой этим "железячным" модулем. Таким образом, все взаимодействие с конкретной USB-железякой инкапсулировано внутри этого модуля. Если железяка отключается, то этот модуль просто завершает все оставшиеся в очереди запросы неуспешно. Нет? |
|
|
Текстовая версия | Сейчас: 28.3.2024, 15:29 |