FreeRTOS的vTaskPrioritySet API在优先级继承场景下的行为疑问

• 优先级继承的临时属性
  优先级继承机制的核心是为了解决优先级反转问题，仅将持有互斥锁的任务优先级临时提升到等待该互斥锁的最高优先级任务的优先级，这个临时优先级的生命周期完全绑定互斥锁的持有状态，设计上不允许外部API随意修改，避免破坏继承逻辑的可预测性。
• 避免破坏取消继承的逻辑正确性
  现有FreeRTOS的互斥锁取消继承逻辑，依赖uxPriority和uxBasePriority的对比判断来实现优先级回退。如果允许在继承状态下直接修改uxPriority，当任务释放互斥锁执行取消继承操作时，会无法判断当前uxPriority是继承得到的还是外部修改的，最终导致优先级回退错误，严重的话会触发优先级反转、任务饥饿等问题。
• 你提出的修改方案会引入复杂的边界问题
  如果采用你给出的判断逻辑，会让互斥锁的优先级维护逻辑复杂度大幅上升：比如任务持有互斥锁时被外部提升到高于继承优先级的等级，之后如果有新的中等优先级任务等待该互斥锁，继承逻辑无法确定是否需要调整当前任务优先级，违背了RTOS内核要求的执行逻辑可确定、延迟可预测的核心设计目标。
• 现有实现不存在功能缺陷
  现有逻辑已经会第一时间更新uxBasePriority为你设置的新优先级，就算新优先级高于当前继承优先级，也只是等到任务执行完临界区、释放互斥锁触发取消继承时，才会将uxPriority更新为更高的新基优先级，不会影响最终的优先级设置效果，反而保证了临界区的执行时序稳定，不会因为外部优先级修改打乱互斥锁的释放节奏。

内容的提问来源于stack exchange，提问作者lenny