linux 内核的futex系统调用

Posted 2020-09-14 bbqz007

futex 设计成用户空间快速锁操作，由用户空间实现fastpath，以及内核提供锁竞争排队仲裁服务，由用户空间使用futex系统调用来实现slowpath。futex系统调用提供了三种配对的调用接口，满足不同使用场合的，分别为noraml futex，pi-futex，以及 requeue-pi。

futex的同步（锁）状态定义由用户空间去执行，futex系统调用并不需要理解用户空间是如何定义和使用这个地址对齐的4字节长的整型的futex，但是pi-futex除外，用户空间必须使用futex系统调用定义的锁规则。用户空间通过总线锁原子访问这个整型futex，进行状态的修改，上锁，解锁和锁竞争等。当用户空间发现futex进入了某种定义需要排队服务的状态时，用户空间就需要使用futex系统调用进行排队，待排队唤醒后再回到用户空间再次进行上锁等操作。当锁竞争时，每次的Lock和Unlock，都必需先后进行用户空间的锁操作和futex系统调用，并且两步并非原子性执行的，Lock和Unlock的执行过程可能会发生乱序。

这是我们希望的

task A	futex in user	futex queue in kerenl	task B
	owned	empty	1. own futex
1.try lock (尝试修改futex)		empty
2.mark waiter (发现锁竞争，修改futex状态)	owned -> waiters	empty
3.futex_wait	0	empty	2. unlock (修改futex，得到旧状态为waiters)
4.       enqueue	0	has waiter	3. futex_wake (发现有锁竞争)
5.       sleep and schedule	0	has waiter	4.           dequeue
	0	empty	5.           wakeup
6.       wokenup	0	empty
7.try lock again (被唤醒后，并不知道还有没有其它任务在等待， 所以锁竞争状态来上锁，以确保自己unlock时进行slowpath， 进行内核检查有没有其它等待的任务)	0 -> waiters	empty
8. own futex	waiters	empty
9. unlock (approach to slowpath)	waiters

但是总会发生我们不希望的情况，虽然总线锁原子操作使得Lock和Unlock的用户空间阶段的操作以Lock为先，让futex进行锁竞争状态，使得Lock和Unlock都要进行slowpath。然而，在它们各自调用futex系统调用时，执行futex_wait的cpu被中断了，futex_wake先于futex_wait执行了。futex_wake发现没有可唤醒的任务就离开了。然后迟到的futex_wait却一无所知，毅然排队等待在一个已经释放的锁。这样一来，如果这个锁将来不发生锁竞争，那么task A就不会被唤醒而被遗忘。

task A	futex in user	futex queue in kerenl	task B
	owned	empty	1. own futex
1.try lock (尝试修改futex)		empty
2.mark waiter (发现锁竞争，修改futex状态)	owned | waiters	empty
3.futex_wait	0	empty	2. unlock (修改futex，得到旧状态为owned | waiters)
interupted	0	empty	3. futex_wake (发现有锁竞争)
interupted	0	empty	4.           quit
4.       enqueue	0	has waiter
5.       sleep and schedule	0	has waiter

所以需要进行排队等待的futex系统调用，都要求将futex当前的副本作为参数传入，futex系统调用在执行排队之前都通过副本和用户空间的futex最新值进行对比，决定是否要返回用户空间，让用户空间重新判断。对于pi-futex的futex_lock_pi系统调用操作入口，并不需要用户空间传入当前futex的副本，是因为用户空间必须使用由futex系统调用对pi-futex的锁规则，futex_lock_pi 函数则以pi-futex的锁规则来判断pi-futex是否被释放。当一个用户空间的futex遵照futex.h对pi-futex锁状态规则，并使用futex系统调用的futex_lock_pi和futex_unlock_pi操作，这个futex就是一个pi-futex。

 

futex系统调用配对的操作入口：

1. normal futex:

static int futex_wait(u32 __user *uaddr, unsigned int flags, u32 val, ktime_t *abs_time, u32 bitset)

static int futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset)

2. pi-futex:

static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, int detect, ktime_t *time, int trylock)

static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags)

3. requeue-pi:

static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, u32 val, ktime_t *abs_time, u32 bitset, u32 __user *uaddr2)

static int futex_requeue(u32 __user *uaddr1, unsigned int flags, u32 __user *uaddr2, int nr_wake, int nr_requeue, u32 *cmpval, int requeue_pi)

 

futex_wait 应用于non-pi futex，futex的规则由用户空间定义，要求用户空间将non-pi futex副本值传入来，过滤工作是由 futex_wait_setup子函数完成，再由 futex_wait_queue_me子函数进行non-pi futex的排队和睡眠等待。

futex_wait_requeue_pi 整合了对futex从non-pi到pi的requeue，以及non-pi到non-pi的requeue。但它首先是对non-pi的futex进行futex_wait，所以它和futex_wait 一样要求用户空间将non-pi futex副本值传入来。所以futex_wait_requeue_pi 如其名字一样，拆分成两个阶段，或者说组合了两种操作，futex_wait和 requeue_pi 。先进行futex_wait ，待被futex_requeue 唤醒后执行requeue_pi 。可以从代码看到futex_wait_requeue_pi 前半段和 futex_wait 代码流程是差不多的。

futex_lock_pi 应用于pi-futex，futex的规则由futex系统调用（头文件）定义，用户空间必须遵从规则来使用。由于规则是由内核定义的，并不要求用户空间传入一个futex当前副本，并且还会在内核中，在使用rt_mutex代理排队等待之前，进行 futex_lock_pi_atomic上锁的尝试，失败后才进入rt_mutex代理排队等待。待排队唤醒后，通过 fixup_owner 和 fixup_pi_state_owner 对用户空间的pi-futex进行上锁。这里有两点注意，rt_mutex的上锁规则是使用task_struct的指针标记，而pi-futex的上锁规则是使用pid(tid)号标记。另外pi-futex的排队也要注意，pi-futex虽然在rt_mutex代理上进行排队，但是还要像non-pi futex一样插入到futex_hash_bucket的链表中，为的不是排队，而是让后面进来的排队，可以在futex_hash_bucket中找出futex_queue，从而得到futex_pi_state（rt_mutex代理所在）。