uCOS-ii互斥对临界区段vs调度器锁定与信号量

Question

我是为运行uCOS-ii的嵌入式系统编写的。我需要原子地写入(和读取)两个整数(值和时间戳，它们应该相互同步)。最简单的方法是用一个关键部分包装两个值的写入，从而禁用任何中断或任务切换。但我被告知，这是非常积极的，它很容易搞乱其他实时的东西，通过禁用中断。

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

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

• 无同步机制：~65
• 临界截面：~185
• 优先级为2的互斥物：~1890
• 锁定调度程序：~1750
• 用1：~1165初始化信号量

我承认，我使用附带的调试器来测量这个值，因为我对此并不熟悉，我也不确定我们是否有一个分析器，但对我来说，CS是最快的，而互斥对象比信号量慢(因为它具有所有的优先级反转处理)。

因此，我是否应该由此得出结论:使用一个关键部分是最好的？或者禁用中断真的是一件非常糟糕的事情吗？一般来说，是否有关于何时使用每个同步机制的指导方针？

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

我怀疑在编写两个值时禁用中断是可以的。但这确实取决于您的应用程序的实时需求，我们不知道它们是什么。

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

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

在嵌入式软件开发中有许多准则，比如最小化关键部分。不要把所有这些准则当作硬性规定.相反，学习并理解为什么每条准则都存在。然后你就会更清楚地知道什么时候该遵守他们，什么时候应该破例。

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