linux 内核的futex pi-support，即pi-futex使用rt_mutex委托

futex的pi-support，也就是为futex添加pi算法解决优先级逆转的能力，使用pi-support的futex又称为pi-futex。在linux内核的同步机制中，有一个pi算法的成例，就是rt_mutex实时锁。而futex的pi-support部分就是委托（代理）给rt_mutex进行实现的。

rtmutex，请参看前面的《linux 内核的rt_mutex (realtime互斥体)》。

non-pi futex，请参看前面的《linux 内核的futex》和《linux 内核的各种futex》。

为了让futex使用rt_mutex进行委托，futex设计中添加了一个futex_pi_state结构，这个结构组合了一个rt_mutex作为委托。并将futex_queue这个排队的entry结构添加对futex_pi_state和rt_mutex_waiter的关联，将futex的排队委托成rt_mutex的排队等待rt_mutex_waiter。同时 task_struct 也添加了pi_state_list链表，以维护确保进程（或线程）在持有pi-futex使用的rtmutex代理时退出，进行恢复。

图的上方为pi-futex添加的结构体，下方为non-pi futex使用的结构体。

pi-futex使用了robust-futex定义的锁规则，内核要求用户空间使用它所理解的锁规则，这样一来就可以将原本non-pi futex在用户空间进行的锁操作也委托给内核完成。所以在pi-support的futex系统调用操作 futex_lock_pi 以及 futex_unlock_pi ，还有pi-futex使用在requeue-pi中的futex系统调用操作 futex_wait_requeue_pi 都会在内核在修改用户空间的futex，完成锁操作。

正如这些操作的函数名称字面一样，futex_lock_pi 执行上锁操作（lock）和提供pi-support的排队（pi），而 futex_wait 只单单提供排队服务（wait）。futex_unlock_pi 执行解锁操作（unlock）和提供pi-support的排队唤醒（pi），而 futex_wake 只单单提供排队的唤醒（wake）。

当用户空间使用 futex_lock_pi 进行上锁的slowpath的场合中，内核从排队中唤醒后会尝试对pi-futex进行上锁（锁状态修改），失败后会再次到rt_mutex代理上排队等待。当内核对pi-futex上锁成功后就会返回用户空间，这时用户空间已经得到了内核上好的锁。

这里必须要注意，futex_lock_pi 和 futex_unlock_pi 都是临界区代码，必须被同步。释放pi-futex上的锁不能够像non-pi futex那样在用户空间任意自由地解锁，必须委托rt_mutex锁。由于pi-futex委托了rt_mutex，因此对pi-futex的trylock也不能non-pi futex那样简单地判断失败然后返回，必须进行rt_mutex的trylock委托，所以pi-futex的trylock在失败时，其开销比较大。

futex_lock_pi 和 futex_unlock_pi 在临界区同步使用的是futex_hash_bucket的保护锁，futex模块的共享等待队列。futex_lock_pi 只有在对rt_mutex进行委托调用（rt_mutex_timed_futex_lock或rt_mutex_trylock）时才会离开临界区，之后又重新回到临界区。虽然pi-futex排队在rt_mutex锁上，但是它的lock和unlock临界区却使用futex模块的共享等待队列的保护锁同步，也就是说，它与跟它共享相同的共享等待队列的futex，都同步地进行futex系统调用。

下面临界区图示

为什么pi-futex在rt_mutex锁上面委托了排队，还要在futex_hash_bucket->chain上入队呢？futex_queue代表着一个futex的waiter，而futex系统调用并不使用额外的映射表维护pi-futex与rt_mutex委托锁的对应关系，而是将同一个pi-futex的所有futex_queue（等待entry）关联到rt_mutex委托锁上，就可以通过futex_key在futex_hash_bucket->chain上找出futex_queue，从而得到这个pi-futex委托的rt_mutex锁。对于futex系统调用来说，它可见的futex等待就是futex_hash_bucket以及入队其中的futex_queue。从futex_hash_bucket搜索出的第一个futex_queue，已经不能看作是第一个唤醒的等待了，必须委托给它关联的rt_mutex进行仲裁。futex_queue除了多对一关联到rt_mutex外，还一对一关联到rt_mutex_waiter。这时wake_futex_pi不是依据futex_queue来唤醒任务，而使用委托的rt_mutex锁的等待队列waiters上的rt_mutex_waiter来唤醒任务。当pi-futex的阻塞任务唤醒后，才会将自己的futex_queue移出futex_hash_bucket。所以可以看到futex_lock_pi在委托rt_mutex进行排队的前后，也生成了一个futex_queue进行futex_hash_bucket的入队和出队。