在抢占式操作系统中，在同一任务中的函数之间使用互斥锁或信号量是否合适？

Question

我正在使用RTOS。除了空闲任务之外，主程序只运行两个任务。

仅在不同的任务之间使用信号量或互斥量是否是良好的编码习惯？还是在同一任务的功能之间？

Answer 1

考虑一下你使用的互斥锁或信号量。它的目的是什么？然后考虑在单个任务的上下文中是否有必要。

互斥锁通常用于保护资源不被异步使用资源的内容同时访问。这里，“异步”意味着使用资源的事物不同步并且可能尝试同时使用资源。现在，单个任务可以同时从两个不同的功能访问资源吗？不，因为一个任务一次只能执行一个功能。由于任务一次只执行一个功能，因此单个任务中的不同功能已经同步。所以我想说，当只有一个任务使用互斥锁时，它不会提供任何好处。

信号量还有其他应用程序，超出互斥锁的应用程序，例如发出事件信号。我想可能存在一些应用程序，其中使用仅由一个任务访问的信号量是有意义的。但是你没有描述你的申请，所以我会留给你自己考虑。

Answer 2

我会说它们主要用于任务间通信/同步/控制资源访问，因此主要用于任务之间而不是同一任务。

可能有情况并非如此，但我现在无法想到任何情况。

就我个人而言，我认为一个任务最好只有一个暂停点，无论是从队列中放置还是接收某些内容，等待互斥锁或信号量等等。有些情况并非总是如此案例，但它确实使调试更容易。

Answer 3

在单个线程中仅访问 的互斥锁没有任何意义 - 锁定尝试将始终成功，因为没有其他线程会锁定它。如果互斥锁是嵌套的 - 即在解锁之前锁定多次，那么除了增加互斥锁的内部计数器之外它也没有任何影响。

在使用互斥锁来保护代码中的资源时可能存在一个争论，这些资源可能会在多个线程中访问维护中的以后;但除非发生这种情况，否则除了消耗CPU周期外，互斥锁没有任何影响。

在这种情况下，信号量的行为更复杂，但信号量的目的是在任务之间进行同步和信令，因此在单个线程中无法实现的目的很少昂贵的简单的柜台或旗帜。

在这种情况下，信号量不如互斥量好;严格意义上的信号量将阻止，如果在给出它之前尝试接受它;因此，如果代码尝试在信号量为空时获取信号量，则任务将阻止（停止运行）。如果信号量超时，则行为将是相当精细的条件延迟，如果没有超时，则任务将停止并且永不恢复，如果超时为零，则不会发生任何事情。

因此，在单个线程中，根据信号量的状态和使用的超时，它将表现为任务暂停，任务延迟或< EM>无操作。使用信号量来实现其中任何一个都可能是一种不必要的混淆，因为任何RTOS都会有API来实现任务暂停和直接延迟。