Embedded 在嵌入式RTOS任务之间传递消息的好方法（但可以优雅地处理消息超时）

我正在使用嵌入式RTO（CMX），但我认为这适用于任何嵌入式RTO。我想在各种任务之间传递消息。问题是，一个任务有时会将其他任务“锁定”很长一段时间（几秒钟）

由于我不再等待邮件在大约100毫秒后被确认，因此如果我在这段时间内发送邮箱邮件，发送邮件的任务将不再等待邮件回复，但接收任务将获取邮件并尝试对其采取行动。问题是，接收任务有一个指向消息的指针，但由于发送任务已移动，指针不再指向消息，这可能会导致巨大的问题

---

一旦消息进入队列，我就无法删除它们。我如何才能优雅地处理这个错误？

这个问题实际上涵盖了几个不同的问题/要点

首先，我想知道为什么有时一个任务占用CPU几秒钟。通常，这是设计问题的迹象。但我不知道你们的系统，可能有一个合理的解释，所以我不会去那个兔子洞

因此，根据您的描述，您是在排队指向消息的指针，而不是消息的副本。这本身没有什么问题。但是你可以遇到你描述的问题

此问题至少有两种解决方案。如果不知道更多，我就说不出哪一个更好

第一种方法是传递消息的副本，而不是指向它的指针。例如，VxWorks消息队列（显然不是CMX队列）让您将消息副本排入队列。我不知道CMX是否支持这种模式，也不知道您是否有足够的带宽/内存来支持这种方法。一般来说，我尽量避免使用这种方法，但有时也有它的位置

第二种方法是让发送方分配消息缓冲区（通常来自我自己的msg/buffer池，通常是一个固定大小内存块的链接列表——但这是一个实现细节——请参阅“内存池”以了解我所说的示例）。无论如何——在分配之后，发送方填写消息数据，将指向消息的指针排入队列，并释放内存块（即消息）的控制权（所有权）。接收器现在负责在读取消息后释放/返回内存

---

在这个问题中可能会提出其他问题，例如，如果发送者将消息“广播”给多个接收者怎么办？接收器如何协调/通信，以便只有最后一个读取器释放内存（垃圾收集）？但从您提出的问题来看，希望第二种解决方案能对您起作用。

我的操作系统任务挂起几秒钟的原因是它位于代码的关键部分，正在引导另一个处理器。虽然我们可以争论这样做的好处（我也同意这不是一个好主意，应该改变），我认为“什么是处理未及时收到任务的操作系统消息的一种优雅的错误处理方式”的概念值得讨论。我是最初的海报，下面是我最终要做的事情：我完全摆脱了邮箱消息，我只使用全局标志来触发任务之间的事件。这实际上只涉及在一个任务中设置一个标志，“拥有”该标志的任务将定期检查并跟踪该标志。对于需要进行读/写操作的实例，我使用信号量来保护资源，需要读或写的任务获取信号量并自行完成工作。看起来很简单，在我的应用程序中效果很好。