A Обертка для аппаратных функций

Question

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

Мы должны записывать и считывать данные в энергонезависимую память. У меня есть библиотека с функциями чтения и записи от компании-продавца. Проблема в том, что эти функции следует вызывать с задержкой между каждым вызовом из-за характеристик оборудования.

Итак, мое решение - начать поток, сделать очередь и сделать мои собственные функции чтения и записи. Поэтому каждый раз, когда вызываются мои функции, данные будут храниться в очереди, а затем в потоке цикла будут фактически прочитаны или записаны в память. Мои функции будут использовать мьютекс для синхронизации доступа к очереди. Моя обложка будет на dll. Основной модуль вызовет мою функцию инициализации dll один раз, чтобы запустить поток, а затем он будет вызывать мои функции чтения/записи много раз из разных потоков.

Мои вопросы: безопасно ли это сделать? исходные функции не являются реентерабельными. Я не знаю, будет ли это проблемой. Есть лучший способ сделать это?

Любая помощь будет оценена по достоинству.

---

Жаль, что я забыл кое-что:

-The язык, который будет использоваться на C++

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

Answer 1

Добавление медиатора в этом контексте является довольно типичным решением, поэтому вы не находитесь в сорняках здесь. Я бы сказал, что вам нужно будет реализовать это , потому что оригинальные функции не являются реентерабельными. Предполагая, что у вас есть доступ к оборудованию. (т. е. вы являетесь водителем.) Если другие люди могут получить доступ к одному и тому же аппаратным средствам, вам придется придумать контракт с более высоким уровнем. Затем ваш поток предоставляет упорядоченный доступ к драйверу. Вы обнаружите, что посредник также позволит вам дросселировать.

Жесткая часть, кажется, зная, когда можно совершать следующий вызов устройства. Есть ли у него какой-то флаг, чтобы вы знали, что он готов к чтению и записи? Некоторые другие вопросы: как вы планируете передавать информацию своим клиентам? Поскольку вы предоставляете асинхронный интерфейс, вам нужно иметь какую-то регистрацию обратного вызова ошибок и т. Д. Взгляните на обычный интерфейс драйвера async для идей.

Но, в целом, звучит хорошая стратегия для начала. Как упоминалось еще один плакат, более конкретные характеристики были бы приятными.