Сценарий «Один потребитель» для нескольких производителей с сигнализацией в операционной системе реального времени (ОСРВ) - PullRequest
0 голосов
/ 06 июля 2018

Я разрабатываю систему реального времени, используя mbed-OS (ОСРВ для архитектуры ARM). Я не инженер-программист, и я хочу знать, является ли следующее решение практичным или нет, и как его улучшить.

Как показано на рисунке, элементы программного обеспечения следующие:

  1. Три разных класса (ClassA, ...) описывают низкий уровень периферийные устройства для сбора данных из трех разных модулей, экземпляры которых передаются по ссылке на три разных потока (поток a, ...).
  2. Используя три очереди (queueA, ...), я отправляю данные в Поток d , который собирает данные из трех других потоков, чтобы объединить их в строку в нужном формате (синтез).
  3. Объединенные данные помещаются в очередь в Thread e и, если некоторые Сценарии (происходящие в первых трех потоках) удовлетворены тем, что данные отправляются в поток g .

Теперь вопросы:

  • Три первых потока собирают данные с разной частотой обновления; Как их синхронизировать в потоке d ?
  • Как лучше всего использовать сигнализацию для информирования других потоков (событие или сигнал?!)
  • Практична ли упомянутая архитектура?

Спасибо.

Block Diagram

1 Ответ

0 голосов
/ 09 июля 2018

Три первых потока собирают данные с разной частотой обновления; Как их синхронизировать в ветке d?

Нужна ли им синхронизация? Поток d предположительно синтезирует выходные данные C на основе самых последних данных из всех трех очередей. Вы можете просто обновить текущие данные для A / B / C по мере их поступления, а при получении любого из них генерировать D из текущих данных. Если данные должны быть гарантированно «свежими», вы можете пометить время поступления данных и использовать их, только если все они достаточно свежие. Если вам нужно собрать свежие данные из всех трех, вы можете сохранить флаг для всех трех, установить по прибытии и сгенерировать D, когда все три флага установлены одновременно, очищая флаги для следующего набора данных. То, как вы это сделаете, действительно зависит от потребностей приложения, и ваше абстрактное описание не предлагает конкретного решения.

Как лучше всего использовать сигнализацию для оповещения других потоков (событие или сигнал?!)

Очереди сообщений блокируют IPC, поэтому, если вы ожидаете одну очередь, поступление данных будет сигнализировать . Я не знаком с MOS RTOS, но большинство RTOS позволяют блокировать только одну очередь. Вы можете объединить все три очереди A, B и C в одну и включить в сообщение идентификатор источника данных, что может быть проще. Однако часто существуют веские причины для отдельных очередей, и для ожидания данных из нескольких очередей вы можете использовать флаг события семафора или задачи, который задается всякий раз, когда A, B или C помещают данные в свои выходные очереди, тогда D будет ожидать семафор / событие и затем опрос всех трех очередей с нулевым тайм-аутом, пока все три не опустеют, прежде чем вернуться к ожиданию.

У вас та же проблема с потоком E, имеющим две входные очереди.

Практична ли упомянутая архитектура?

Кажется правдоподобным - абстрактный характер вашего описания не позволяет определить, является ли он работоспособным или уместным в вашем конкретном приложении, но, по крайней мере, он не безумен.

...