synchronization - uCOS-ii 互斥体 vs 临界区 vs 调度程序锁定 vs 信号量

Question

我正在为运行 uCOS-ii 的嵌入式系统写作。我需要以原子方式写入（和读取）两个整数（值和时间戳，它们应该彼此同步）。最简单的方法是用临界区包装这两个值的写入，从而禁用任何中断或任务切换。但有人告诉我这是非常激进的，而且很容易通过禁用中断来搞乱其他实时的东西。

但是写两个整数是一个很小的操作，我不确定使用互斥锁的整个簿记是否值得。

所以我做了一些测量。我测量了将这两个值写入一百万次所需的时间，并计算了所需的毫秒数。所有这些都是在一个任务中完成的，只是为了了解不同同步机制的开销。结果如下：

我承认我用附加的调试器测量了这个，因为我是新手，我不确定我们是否有分析器，但对我来说 CS 最快并且互斥体比信号量慢是有道理的（因为它具有所有优先级反转处理）。

那么我应该由此得出结论，使用临界区是最好的吗？还是禁用中断真的是一件非常糟糕的事情？一般来说 - 是否有关于何时使用每种同步机制的指南？

更新：一位同事建议使用自旋锁。显然，这将比更高级的同步机制具有更小的开销。但我想知道在这种特定情况下它是否比关键部分更好。

更新 2：想一想，因为我们只有一个 CPU，所以自旋锁不会有任何好处。它只会旋转直到上下文切换......

score 3 · Accepted Answer

如果停止时间小于其他机制的开销并且小于任何中断处理程序或任务的最大允许延迟，那么更简单的蛮力方法可能是最合适的。

但是，您需要确定关键部分的长度不会在维护期间增长到无法接受的程度，或者该机制的使用不会被视为在没有适当考虑的情况下在任何地方使用它的绿灯。因此，我建议您在明确的评论中记录其使用情况，并附上其理由和限制，即您为什么这样做，以及在什么情况下可以保证在满足实时截止日期方面是安全的。

score 1 · Accepted Answer

对于 uCOS-II 的小型同步操作，只需禁用中断即可。

uCOS-II 提供的所有机制都将禁用中断一段时间，该时间长于读取或写入两个整数所需的时间。在这种情况下使用它们实际上会损害中断延迟。

score 0 · Accepted Answer

我怀疑在写入两个值时禁用中断会很好。但这实际上取决于您的应用程序的实时要求，我们不知道那些是什么。

执行 100 万次操作需要 185 毫秒吗？这是否意味着您将平均禁用中断 185 纳秒？您是否有任何实时要求，额外的 185 纳秒会导致您错过最后期限并失败？

查看您正在考虑的互斥锁和其他服务的 uC/OS-ii 源代码。我怀疑您会发现这些服务会在短时间内禁用中断。使用这些服务可能会导致禁用中断的时间比写入这两个值所需的时间更长。

嵌入式软件开发中有许多准则，例如最小化关键部分。不要将所有这些指导方针视为硬性规定。相反，学习并理解每条指南存在的原因。然后你会更好地知道何时遵守它们以及何时破例。

您希望最小化关键部分，这样您就不会长时间禁用中断以致错过中断或实时截止日期。几秒钟内禁用中断几乎肯定是不好的。在许多应用程序中，禁用几毫秒的中断可能会很糟糕。对于许多应用程序来说，禁用几纳秒的中断可能是可以的。

3 回答 3