rt-thread优先级配置失效问题

[LearnigF]

/* get highest priority inside its taken object and its init priority */
rt_inline rt_uint8_t _thread_get_mutex_priority(struct rt_thread* thread)
{
    rt_list_t *node = RT_NULL;
    struct rt_mutex *mutex = RT_NULL;
    rt_uint8_t priority = thread->init_priority;

    rt_list_for_each(node, &(thread->taken_object_list))
    {
        mutex = rt_list_entry(node, struct rt_mutex, taken_list);
        rt_uint8_t mutex_prio = mutex->priority;
        /* prio at least be priority ceiling */
        mutex_prio = mutex_prio < mutex->ceiling_priority ? mutex_prio : mutex->ceiling_priority;

        if (priority > mutex_prio)
        {
            priority = mutex_prio;
        }
    }

    return priority;
}

这里获取优先级会使用线程的初始优先级，假设对一个已经创建好的线程使用了设置优先级的线程API，那么之后在使用线程锁的时候，由于rtthread的防止优先级翻转的机制，会导致当前线程的优先级重新变成线程的初始优先级。

[polarvid]

倒不如说 rt_thread_control(RT_THREAD_CTRL_CHANGE_PRIORITY) 这个 API 的设计就是这么个逻辑，它只是修改一个“临时”优先级。而优先级翻转同样是修改这个临时优先级。如果用户和 mutex 都这么做了，两边很自然的就冲突了。因为 init_prio 在 mutex 优先级翻转中，就是作为锚定的“真实”优先级。它不可能参考线程的当前优先级，因为它自己就会改变这个变量。所以你说的情况与其说是 bug，应该说这个 API 与 mutex 算法的特性，或者说 rt_thread 这个成员属性的本来意义。

当然，这只是我个人对 rt_thread_control(RT_THREAD_CTRL_CHANGE_PRIORITY) 这个 API 的理解。如果要实现你期望的语义，应该有一个修改 init_prio 的 API。当然这个需求合不合理就得另当别论了。