linux 内核的futex - requeue 以及 requeue-pi
Posted bbqz007
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了linux 内核的futex - requeue 以及 requeue-pi相关的知识,希望对你有一定的参考价值。
futex为更好支持pthread_cond的实现(,最主要是broadcast),设计了requeue功能,并以futex系统调用提供操作接口,包括一对配对的操作 futex_wait_requeue_pi 以及 futex_requeue。
mutex互斥体,确保临界区之间互斥(mutual exclusion),但不能满足不同临界区之间的前驱后继的关系,所以可以通过在临界区A使用condition variable条件变量,等待另一临界区B的发出信号指令。
Condition Variables Synchronization mechanisms need more than just mutual exclusion; also need a way to wait for another thread to do something.
临界区A,与临界区B虽然使用了mutex,确保彼此之间互斥(mutual exclusion)。但是同时使用了condvar,保证临界区B前驱,临界区A后继,即临界区A等待临界区B先完成某些事。
一个condvar必须从属于(belong to)一个mutex。
因此condvar的等待(wait)包含了两次等待,或两个队列等待。一个是condvar信号的等待(队列),另一个是它所属的mutex锁的等待(队列)。这使得一次condvar wait必须先释放mutex,然后依次等待condvar信号和mutex。这意味着等待的线程必须进行两次等待和两次唤醒。
对condvar发起信号signal,就是唤醒其中一个等待在condvar的线程,让它转而等待condvar所属的mutex,再次回到临界区执行。而broadcast最简单的方法就是将所在等待在condvar的线程统统唤醒。
当对condvar进行broadcast时,多个等待在condvar的线程被唤醒回到用户空间,一起去竞争condvar所属的mutex,而又每个线程又因锁竞争必须再次回到内核进行排队等待,从而造成了多次的线程切换,系统调用的浪费。
为了改善这种浪费,可以将一个等待在两个等待队列之间的转换,优化在一次调用中进行,避免多个线程被唤醒去竞争锁。这样的功能就是futex提供的requeue。
被requeue后的waiter(,调用futex_wait_requeue_pi而阻塞的线程),必须等待condvar所属的mutex去唤醒。当waiter从futex_wait_requeue_pi系统调用阻塞中被唤醒,并不表示已经获得了condvar所属的mutex锁,而是要去竞争这个锁。
requeue将这个过程的condvar和mutex看作为futex1和futex2。
futex_requeue函数原型为
static int futex_requeue(u32 __user *uaddr1, unsigned int flags, u32 __user *uaddr2, int nr_wake, int nr_requeue, u32 *cmpval, int requeue_pi);
这个函数的功能是,将uaddr1对应的futex等待队列出队最多 (nr_wake + nr_requeue) 个futex_q,先对出队的futex_q进行唤醒nr_wake个,剩下的才进行requeue到futex2等待队列。而pthread_cond_broadcast固定设定参数 nr_wake = 1,nr_requeue = INT_MAX。就是说在broadcast的时候只会唤醒一个线程去竞争futex2,其余阻塞在futex1的线程都会出队再入队到futex2的等待队列。
requeue-pi 就是condvar所属的mutex是一个使用pi协议的mutex,即futex2是pi-futex,requeue对一个non-pi futex的waiters出队再入队到pi-futex等待队列进行特殊的优化。futex_requeue函数只会将可以马上获得pi-futex锁的线程唤醒,也就是说对每一个requeue到pi-futex的waiter都先尝试锁pi-futex,尝试成功的才能被唤醒,直到有线程被唤醒,其余waiter就直接requeue到pi-futex,而不再进行锁尝试。虽然futex_proxy_trylock_atomic并不像futex_lock_pi那样会去调用rt_mutex_trylock,但是与non-pi到non-pi的requeue,增加了额外的尝试。
下面是requeue non-pi 和 requeue-pi 分支的逻辑对比:
以上是关于linux 内核的futex - requeue 以及 requeue-pi的主要内容,如果未能解决你的问题,请参考以下文章
v79.01 鸿蒙内核源码分析(用户态锁篇) | 如何使用快锁Futex(上) | 百篇博客分析OpenHarmony源码
v80.01 鸿蒙内核源码分析(内核态锁篇) | 如何实现快锁Futex(下) | 百篇博客分析OpenHarmony源码
v80.01 鸿蒙内核源码分析(内核态锁篇) | 如何实现快锁Futex(下) | 百篇博客分析OpenHarmony源码