我正在为运行uCOS-ii的嵌入式系统写作。 我需要自动写入（和读取）两个整数（值和时间戳，它们应该彼此同步）。 最简单的方法是用临界区包装两个值的写入，从而禁用任何中断或任务切换。但我被告知这是非常激进的，并且很容易通过禁用中断来搞乱其他实时内容。
但写两个整数是一个很小的操作，我不确定使用互斥锁的整个记录是否值得。
所以我做了一些测量。我测量了将这两个值写入一百万次并计算所花费的毫秒数所需的时间。所有这些都是在一个任务中完成的，只是为了理解不同同步机制的开销。结果如下：
我承认我用连接的调试器测量了这个，因为我是新手，我不确定我们是否有一个分析器，但是对我来说CS是最快的并且互斥量慢于一个信号量（因为它具有所有优先级反转处理）。
因此，我应该从中得出结论，使用关键部分是最好的吗？或者，禁用中断真的是一件非常糟糕的事情吗？ 一般来说 - 是否有关于何时使用每种同步机制的指导原则？
更新：一位同事建议使用自旋锁。显然，这将比更高级的同步机制具有更小的开销。但我想知道它是否比这个特定情况下的关键部分更好。
更新2：想想看，因为我们有一个单独的CPU，旋转锁定不会有任何好处。它会旋转直到上下文切换......
答案 0 :(得分：3)
如果停止时间小于其他机制的开销并且小于任何中断处理程序或任务的最大允许延迟，那么更简单的暴力方法可能是最合适的。
然而，您需要确定临界区的长度在维护期间不会无法接受地增长，或者在没有适当考虑的情况下使用该机制不会被视为在任何地方使用它的绿灯。因此，我建议您在明确的评论中记录其使用的理由和约束，即为什么要这样做，以及在什么情况下保证在满足实时截止日期方面是安全的。
答案 1 :(得分：1)
对于使用uCOS-II的小型同步操作，只需禁用中断即可。
uCOS-II提供的所有机制将禁用中断的时间超过读取或写入两个整数所需的时间。在这种情况下使用它们实际上会损害中断延迟。
答案 2 :(得分：0)
我怀疑在写两个值时禁用中断会很好。但它实际上取决于您的应用程序的实时要求，我们不知道它们是什么。
操作100万次是185毫秒吗？这是否意味着您平均会禁用185纳秒的中断？你有任何实时要求，额外的185纳秒会导致你错过截止日期并失败吗？
查看您正在考虑的互斥锁和其他服务的uC / OS-ii源代码。我怀疑你会发现这些服务会在短时间内禁用中断。使用这些服务可能会导致中断被禁用的时间超过写入这两个值所需的时间。
嵌入式软件开发有许多指导原则，例如最小化关键部分。不要将所有这些指南视为严格的规则。而是学习并理解为什么每个指南都存在。然后你会更好地了解何时遵守它们以及何时例外。
您希望最小化关键部分，以便您不会长时间禁用中断，以至于错过了中断或实时截止时间。几秒钟禁用中断几乎肯定是坏事。在许多应用程序中，禁用中断毫秒可能会很糟糕。对于许多应用来说，禁用纳秒中断可能没问题。