VxWorks如何处理优先级继承？
我们有 3 个任务以不同的优先级运行：A (120)、B (110)、C (100)。 A 采用带有反转安全标志的互斥信号量。 任务 B 执行 semTake，这导致任务 A 的优先级提升到 110。 随后，任务 C 执行 semTake。 任务A的优先级现在是100。
此时，A释放信号量，C抓住它。 我们注意到 A 的优先级并没有降回原来的优先级 120。 难道不应该立即恢复A的优先级吗？
We have 3 tasks running at different priorities: A (120), B (110), C (100).
A takes a mutex semaphore with the Inversion Safe flag.
Task B does a semTake, which causes Task A's priority to be elevated to 110.
Later, task C does a semTake. Task A's priority is now 100.
At this point, A releases the semaphore and C grabs it.
We notice that A's priority did not go back down to its original priority of 120.
Shouldn't A's priority be restored right away?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理想情况下，当继承的优先级为
降低，它将以逐步的方式完成。 正如每个
导致优先级提高的依赖关系被删除，
继承的优先级应该下降到以下优先级
剩余的最高依赖性。
例如：
任务 A（100 增加到 80）有两个互斥体（X 和 Y）
任务 B (pri 90) 和任务 C (pri 80) 分别处于待处理状态
为了。 当任务 A 将互斥量 Y 放弃给任务 C 时，我们可能期望它
优先级将下降到 90。当它最终将互斥体 X 交给任务 B 时，
我们预计它的优先级会回落到 100。
优先级继承在 VxWorks 中不是这样工作的。
它的工作原理取决于您使用的 VxWorks 版本。
VxWorks 6.0 之前的版本
优先级保持“升高”状态，直到任务具有
锁定互斥体信号量放弃其最后反转安全互斥体
信号。
使用上面的示例，当任务 A 放弃互斥体 Y 时
对于任务 C，其优先级仍为 80。在它放弃互斥体 X 后
任务 B，那么它的优先级将降回 100（跳过 90）。
让我们把 1 号曲线球加入其中。 如果任务 A 锁定了互斥体怎么办
Z虽然这一切都在进行，但没有人在等待Z？ 在那里面
这种情况下，优先级将保持在80，直到Z被放弃——然后
它会回落到 100。
为什么要这样做？
很简单，而且对于大多数情况来说都很好
足够的。 然而，这确实意味着当“曲线球#1”进入时
玩时，优先级将在更长的时间内保持高于
是必要的。
VxWorks 6.0+
现在的优先级
保持提升状态，直到任务锁定互斥锁
信号量放弃最后一个反转安全互斥体，这有助于
提高优先级。
这一改进避免了以下问题
“曲线球#1”。 它确实有其自身的局限性。 例如，如果
任务 B 和/或任务 C 在等待任务 A 放弃时超时
信号量，任务 A 的优先级不会被重新计算
直到它放弃信号量。
Ideally, when the inherited priority level is
lowered, it will be done in a step-wise fashion. As each
dependency that caused the priority level to be bumped up is removed,
the inherited priority level should drop down to the priority level of
the highest remaining dependency.
For Example:
task A (100 bumped up to 80) has two mutexes (X & Y)
that tasks B (pri 90) and task C (pri 80) are respectively pending
for. When task A gives up mutex Y to task C, we might expect that its
priority will drop to 90. When it finally gives up mutex X to task B,
we would expect its priority level to drop back to 100.
Priority inheritance does not work that way in VxWorks.
How it works depends on the version of VxWorks you are using.
pre-VxWorks 6.0
The priority level remains "bumped up" until the task that has the
lock on the mutex semaphore gives up its last inversion safe mutex
semaphore.
Using the example from above, when task A gives up mutex Y
to task C, its priority remains at 80. After it gives up mutex X to
task B, then its priority will drop back to 100 (skipping 90).
Let's throw curve ball #1 into the mix. What if task A had a lock on mutex
Z while all this was going on, but no one was pending on Z? In that
case, the priority level will remain at 80 until Z is given up--then
it will drop back to 100.
Why do it this way?
It's simple, and for most cases, it is good
enough. However, it does mean that when "curve ball #1" comes into
play, the priority will remain higher for a longer period of time than
is necessary.
VxWorks 6.0+
The priority level now
remains elevated until the task that has the lock on the mutex
semaphore gives up its last inversion safe mutex that contributed to
raising the priority level.
This improvement avoids the problem of
"curve ball #1". It does have its own limitations. For example, if
task B and/or task C time(s) out while waiting for task A to give up
the semaphores, task A's priority level does not get recalculated
until it gives up the semaphore.