防止设备通信中的瓶颈答案

【问题标题】：Preventing a bottleneck in devicecommunication防止设备通信中的瓶颈
【发布时间】：2018-10-11 09:45:27
【问题描述】：

我有一个非常抽象的问题。我正在做一个需要持续设备通信的项目。我正在将多个设备集成到带有触摸屏的外部处理单元上以执行某些方法。 IE。触摸屏上的“开始视频通话”按钮激活继电器，打开显示设备、摄像头设备和麦克风设备等。

另一方面，我也在尝试监控这些设备。他们目前处于什么状态？它们是否启用/禁用？显示设备当前打开的是什么输入？

到目前为止，我已经提出了两种解决方案来防止通信中的瓶颈，我不断轮询（即每两到五秒以保持准确和最新的状态）开启状态和显示设备的输入状态。

利用线程，这样我就可以将不同的命令排入队列并异步执行它们。通过异步读取响应，所有通信都应该很好地间隔开，但我会有一条非常“繁忙”的通信线路，这会对处理单元造成影响。
在事件的帮助下，显示设备将其状态更改通知处理器。这会减轻通信线路的压力，但我觉得这很容易被打断。如果设备没有正确抛出它的事件（或事件被错过），则监控状态与实际状态不对应。

我很好奇是否有其他方法可以解决这个问题。到目前为止，我倾向于第二个，因为它对处理单元的压力要小得多，我只是觉得我应该建立很多保护措施来防止实际设备状态的不准确表示。

该项目在 .Net 3.5 上以 C# 运行。

【问题讨论】：

您好，一般和最抽象的形式，不保证会传递事件。另一方面;我从来没有遇到过不是由于我自己缺乏编程技能而导致的未交付事件。因此，除非您遇到问题，否则选项 2 将是“更好”的方式。顺便说一句：有时您可以通过实现功能来纠正这些状态。例如：用于恢复状态的后退按钮，在转换到下一个状态之前检查当前状态，超时机制。最后提示：尝试实现statemachine 以防止过多的if/else 接线。

标签： c# .net multithreading performance

【解决方案1】：

轮询有效，但既不好玩也不理想。反应式是最好的，但正如您所提到的，可能会出现一些问题，以确保您仍在收听设备，而不仅仅是无所事事。在这种情况下，它可以优化这两个过程。在您等待或很久没有收到回复时进行投票，并在您的投票返回良好信息时进行聆听，通过投票。

也就是说，您不必担心对各个线程进行轮询而对单元征税过多。这听起来像是一个目的设备，所以只要您没有一直运行它或将其压力最大化，那么使用您的资源就完全可以了。

【讨论】：

所以基本上尝试结合这两种实现？每当一个小时未触发事件时，我将轮询一次，如果活动状态符合受监视状态，如果尚未触发事件，我将在一个小时内再次轮询？诚实听起来像是一个可靠的实现。正如@Stefan 已经暗示的那样，我有点怀疑依赖事件的原因是因为我对自己的编程技能没有信心。
@Ciphra 好吧，不要怀疑自己或你的技能。如果您犯了错误，请了解问题所在并进行修复。但是，除非您有办法知道设备仍处于连接状态，否则两者的混合将起作用。你基本上需要某种类型的心跳，无论是内置的还是自己设计的，来告诉你设备在那里。然后你只需要准确地管理设备的状态。没有完美的解决方案。
大多数设备都与 TCPClient 连接，该 TCPClient 具有在连接状态更改时触发的事件。这可以作为你提到的心跳。我仍然倾向于轮询和监听的组合实现。
@Ciphra 你是对的，TCP 内置了它，这就是我所指的。什么设备/操作系统正在初始化 TCP？
它是一种类似服务器的设备，通常被称为（在这里的工作区）作为处理器。它启动程序/系统并保持运行，除非它因为错误的代码而中断，或者你告诉它停止。设计的程序/系统大多只是集成多个设备以通过单个控制面板进行控制，通常是触摸面板，但也可能是模拟控制面板。我相当肯定他们也在其中运行一个自写的操作系统。