Предотвращение узких мест в устройстве связи - PullRequest
0 голосов
/ 01 мая 2018

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

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

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

  1. Используйте многопоточность, чтобы я мог ставить в очередь различные команды и выполнять их асинхронно. При чтении асинхронного ответа все коммуникации должны быть хорошо разнесены, но у меня была бы очень «занятая» линия связи, что сказалось бы на процессоре.
  2. С помощью событий устройство отображения уведомляет процессор об изменении своего состояния. Это сняло бы много напряжения с линии связи, но я чувствую, что это очень легко нарушить. Если устройство не генерирует свои события правильно (или события пропущены), отслеживаемое состояние не соответствует фактическому состоянию.

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

Проект выполняется в C # на .Net 3.5.

1 Ответ

0 голосов
/ 01 мая 2018

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

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

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