flag=RT_IPC_FLAG_FIFO的mutex释放时,优先级反转

[cc-caixf]

1.初始化mutex的flag=RT_IPC_FLAG_FIFO.
2.多个不同优先级线程take这个mutex
3.拥有mutex的线程rt_mutex_release

if (!rt_list_isempty(&mutex->parent.suspend_thread))
        {
            /* get suspended thread */
            thread = rt_list_entry(mutex->parent.suspend_thread.next,
                                   struct rt_thread,
                                   tlist);

            RT_DEBUG_LOG(RT_DEBUG_IPC, ("mutex_release: resume thread: %s\n",
                                        thread->name));

            /* set new owner and priority */
            mutex->owner             = thread;
            mutex->original_priority = thread->current_priority;
            mutex->hold ++;

            /* resume thread */
            rt_ipc_list_resume(&(mutex->parent.suspend_thread));

            need_schedule = RT_TRUE;
        }

这时当前代码会让队列中的第一个thread拥有mutex,符合FIFO,但可能队列中会有更高优先级的thread,当前代码是否需要考虑释放mutex时,使用队列中最高优先级来修改当前thread的优先级?
或者RTTHREAD认为这种情况该使用mutex的flag=RT_IPC_FLAG_PRIO?

[BernardXiong]

是的，这个好像有份PR，#3647

[KyleChenjh]

该问题已经修复，在使用上有个建议，就是在使用 RT_IPC_FLAG_FIFO 时候，由于未进行优先级排列，如果suspend链表上的最后几个线程优先级很高，那么互斥任务在release的时候将自身优先级提升到链表的最高优先级，这就会造成 不需要使用该互斥锁的中间优先级的任务 要一直等待整个链表结束（因为高优先级任务在最后需要等待）才能运行，才能避免优先级反转。如果这个等待整个链表的时间的是不能容忍的，那么建议使用 RT_IPC_FLAG_PRIO 的方式进行。

[mysterywolf]

@KyleChenjh 麻烦再在这里边说一下吧 #3912

[KyleChenjh]

@mysterywolf 嗯嗯，我整理一下记录到指南里。