当前位置：文江博客话题详情

为什么互斥体无法从 ISR 中释放

发布于 2024-10-05 10:26:40 字数 91 浏览 8 评论 0原文

Vxworks 声明互斥信号量：不能在 ISR 内部给出，而该条件对于二进制和计数信号量有效。

我无法理解同样的原因。

谢谢，扎克斯。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夢归不見 2024-10-12 10:26:40

请记住，互斥锁必须首先被获取/获取，然后释放/给出。
此外，获取互斥体的任务拥有它。这可以防止另一个任务释放它不拥有的互斥体。

在这种情况下，很明显，由于 ISR 无法获取互斥锁（或与此相关的任何信号量 - 这是一个阻塞操作），因此它无法提供互斥锁。

ISR 很可能会给出二进制或计数信号量来向任务发出发生某事的信号。但互斥体始终是一对接受/给予。

为了澄清一点。在 VxWorks 中，ISR 上下文与任务上下文不同相同！
以下情况无效：

  Task A            ISR
  semTake(mutex)
   ....
                    semGive(mutex)

任务 A 拥有互斥锁。当 ISR 运行时，它在完全不同的上下文中执行。当前大多数处理器都有一个单独的 ISR 堆栈。既然任务 A 拥有互斥体，ISR 怎么可能放弃它呢？事实上，当 A 拥有互斥体时，你有什么保证 ISR 会触发。
即使假设您“可以”在 ISR 中提供互斥体，您将如何处理以下情况：

 Task A                       Task B                 ISR
  semTake(mutex)
  ...
  <context switch happens>
                              <B runs>
                                                  semGive(mutex)

任务 A 由于与互斥体无关的调用而被切换，并且任务 B 运行。现在，ISR 在 B 运行时执行。发出的 ISR 仍然有效吗？

不管怎样，一个简单的事实是互斥锁总是用在一对 Get/Set 中。我没有看到有一个单独的 semGive 的用例。

您是否考虑到需要 ISR 上下文中的 semGive 的特定情况？

Remember that a Mutex must first be acquired/taken then released/given.
In addition, the task that acquires the mutex owns it. This prevents another task from releasing a mutex it doesn't own.

With that being the case, it becomes clear that since an ISR cannot acquire a mutex (or any semaphore for that matter - it's a blocking operation), then it follows that it can't give the mutex.

It is quite possible for an ISR to do give a Binary or Counting semaphore to signal a task that something happens. But mutexes are always a take/give pair.

To clarify a point. In VxWorks, the ISR context is not the same as the context of a task!
The following scenario is invalid:

  Task A            ISR
  semTake(mutex)
   ....
                    semGive(mutex)

Task A owns the mutex. When the ISR runs, it executes in a totaly different context. Most current processors have a separate ISR stack. Since Task A owns the mutex, how could the ISR give it up? In fact, what guarantee do you have that the ISR will fire while A has the mutex.
Even assuming you "could" give a mutex in an ISR, how would you handle the following scenario:

 Task A                       Task B                 ISR
  semTake(mutex)
  ...
  <context switch happens>
                              <B runs>
                                                  semGive(mutex)

Task A gets switched out due to a call unrelated to the mutex, and Task B runs. The ISR now executes while B was running. Would it still be valid for the ISR to be given?

Regardless of all this, the simple fact is that a mutex is always used in a pair of Get/Set. I fail to see a use case where you would have an isolated semGive.

Is there a specific situation you have in mind that would require a semGive from an ISR context?

回复收藏 0 原文