我们的项目有40多个应用程序，从50Hz到1000Hz（通常为250Hz）交换多达90条消息。某些应用程序的执行速度低于驱动它们的输入数据，我们希望这些应用程序对已发布消息的最新副本执行操作。临时解决方案是在计划的管道上订阅输入数据，将每个消息缓存在本地副本中，直到应用程序“唤醒”以对缓存的消息进行操作。这是有用的，因为应用程序会对消息的最新副本进行操作，但是由于上下文切换过多，因此对性能产生了巨大影响。我们已经提出了多个更永久的解决方案，但认为我们会尝试向社区民意调查。
在考虑本地维护的CFE / CFS更改时，我不建议任何正式的CFE / CFS更改。这些仅是出于我们的目的，除非社区对回馈感兴趣。我试图避免讨论社区范围的体系结构更改。仅在寻找想法和/或反馈。也许我们可以选择对其他人可能有用的解决方案。
背景
- 我们当前正在运行内部编写的POSIX OSAL，而没有mqueue或套接字调用，这使我们能够以更高的速率运行。
- 我们正在运行从6.5.0a分叉的经过稍微修改的CFE。唯一真正的内容更改是支持多核执行的更新。
- 我们通常每秒交换大约3000条消息。
- 在具有双主频为667MHz的ARM的Zynq 7010上运行。
- 每个核心约占80％，包括系统开销。
- 我们最大的CPU占用的逻辑很少。这是最大的CPU工作量，因为它是高优先级任务，并且订阅了来自低优先级任务的许多高速率消息，因此每秒经历数千次上下文切换。
目标（按顺序）
- 为应用程序提供API，以最有效的方式仅接收订阅消息的最新副本，以减少上下文切换和CPU利用率。
- 提供与发送者/发布者无关的API，并且可以使用现有的接收者/订阅者API以及实现的任何新的“当前值” API进行工作。
- 提供一个与接收者/订阅者无关的API，并且该API可能只是从当前实现到“当前值”实现的配置项。
- 提供一个通用的API，该API可以适应其他用例，可以预见或无法预见。
- 尽可能少地叉CFE / CFS。
正在考虑当前选项（无顺序）
- 按原样使用CFE SB ZeroCopy API，无需更改代码。
- 实施独立于CFE本身的黑板模式。
- 通过CFE SB管道和OSAL队列来实现初始化时间可选的FIFO（它们当前是什么）或LIFO队列，从而使接收者/用户可以接收最新的n条消息。
- 实施当前值（深度1）管道，该管道会在推送新版本之前自动弹出旧版本。
现在敲我的脖子...有任何输入或反馈吗？