信号量机制中的down和up函数

转自：https://blog.csdn.net/fzubbsc/article/details/37737159

参考：

https://blog.csdn.net/liuxd3000/article/details/17913363

http://blog.chinaunix.net/uid-25845340-id-3017214.html 

https://blog.csdn.net/xiao229404041/article/details/7031776

查阅文件：

kernel\linux\linux-4.4.3\kernel\locking\semaphore.c

kernel\linux\linux-4.4.3\include\linux\semaphore.h

DOWN操作：linux内核中，对信号量的DOWN操作有如下几种：

1、void down(struct semaphore *sem); //不可中断

down接口用于请求一个信号量。此函数的调用将会到致调用线程的睡眠,  直到获取到信号。同时，该函数的调用不允许中断。
在此函数中首先进行信号量资源数的查看，如果信号量数据(count)不为0，则把其减1，并返回，调用成功；否则调用__down进行等待，调用者进行睡眠。

2、int down_interruptible(struct semaphore *sem);//可中断

该函数功能和down类似，不同之处为，down不会被信号（signal）打断，但down_interruptible能被信号打断，因此该函数有返回值来区分是正常返回还是被信号中断，如果返回0，表示获得信号量正常返回，如果被信号打断，返回-EINTR。

 

3、int down_killable(struct semaphore *sem);//睡眠的进程可以因为受到致命信号而被唤醒，中断获取信号量的操作。

down_killable与down_interruptible相近，最终传入的__down_common的实参有所不同(TASK_KILLABLE和TASK_INTERRUPTIBLE)，所以，在此不再进行分析。

4、int down_trylock(struct semaphore *sem);//试图获取信号量，若无法获得则直接返回1而不睡眠。返回0则 表示获取到了信号量

down_trylock接口用于试着获取一个信号量，但是，此接口不会引起调用者的睡眠。不管有无可用信号量，都马上进行返回，如果返回0，则获取信号量成功，如果返回1，则获取失败。所以，在调用此接口时，必须进行返回的值的查看，看是否获取成功。

5、int down_timeout(struct semaphore *sem,long jiffies);//表示睡眠时间是有限制的，如果在jiffies指明的时间到期时仍然无法获得信号量，则将返回错误码。

down_timeout接口的实现过程与down接口的实现过程差不多，只是此接口 可以自定义超时时间，也就是如果在超时间内不能得到信号量，调用者会因为超时而自行唤醒。其实现过程如下，请注意超时参数的传入。其中TASK_UNINTERRUPTIBLE

在以上五种函数中，驱动程序使用的最频繁的就是down_interruptible函数，以下将对该函数进行分析。

down_interruptible函数的定义如下：

函数分析：函数首先通过spin_lock_irqsave的调用来保证对sem->count操作的原子性。如果count>0，表示当前进程可以获得信号量，将count的值减1然后退出。如果count不大于0，表明当前进程无法获取信号量,则调用__down_interruptible，后者会继续调用__down_common。

__down_common 函数定义如下：

static inline int __sched __down_common(struct semaphore *sem, longstate,

longtimeout)

{

struct task_struct *task= current;

struct semaphore_waiterwaiter;

list_add_tail(&waiter.list,&sem->wait_list);

waiter.task = task;

waiter.up = 0;

for (;;) {

if(signal_pending_state(state, task))

gotointerrupted;

if (timeout <=0)

gototimed_out;

__set_task_state(task,state);

spin_unlock_irq(&sem->lock);

timeout =schedule_timeout(timeout);

spin_lock_irq(&sem->lock);

if (waiter.up)

return 0;

}

timed_out:

list_del(&waiter.list);

return -ETIME;

interrupted:

list_del(&waiter.list);

return -EINTR;

}

函数分析：在__down_common函数数执行了以下操作。

(1)将当前进程放到信号量成员变量wait_list所管理的队列中。

(2)在一个for循环中把当前的进程状态这是为TASK_INTERRUPTIBLE,在调用schedule_timeout使当前进程进入睡眠状态，函数将停留在schedule_timeout调用上，知道再次被调度执行。

(3) 当该进程再一次被调度时，按原因执行相应的操作：如果waiter.up不为0说明进程被该信号量的up操作所唤醒，进程可以获得信号量。如果进程是因为被用户空间的信号所中断或超时信号所引起的唤醒，则返回相应的错误代码。 

UP操作：LINUX内核只提供了一个up函数

up函数定义如下：

void up(struct semaphore *sem)

{

unsigned long flags;


spin_lock_irqsave(&sem->lock,flags);

if(likely(list_empty(&sem->wait_list)))

sem->count++;

else

__up(sem);

spin_unlock_irqrestore(&sem->lock,flags);

}

函数分析：如果sem的wait_list队列为空，则表明没有其他进程正在等待该信号量，那么只需要把sem的count加1即可。如果wait_list队列不为空，则说明有其他进程正睡眠在wait_list上等待该信号，此时调用__up(sem)来唤醒进程：

__up()函数定义如下：

static noinline void __sched __up(struct semaphore *sem)

{

struct semaphore_waiter*waiter = list_first_entry(&sem->wait_list,

structsemaphore_waiter, list);

list_del(&waiter->list);

waiter->up = 1;

wake_up_process(waiter->task);

}

函数分析:在函数中，调用了wake_up_process来唤醒进程，这样进程就从之前的__down_interruptible调用中的timeout=schedule_timeout(timeout)处醒来，wait-up=1, __down_interruptible返回0，进程获得了信号量。

up()与down()函数之间的联系：由上面对两个函数的分析可以知道，__down_common函数中timeout=schedule_timeout(timeout) 有着很重要的作用。

Note：一个进程在调用down_interruptible()之后，如果sem<0，那么就进入到可中断的睡眠状态并调度其它进程运行， 但是一旦该进程收到信号，那么就会从down_interruptible函数中返回。并标记错误号为:-EINTR。一个形象的比喻：传入的信号量为1好比天亮，如果当前信号量为0，进程睡眠，直到（信号量为1）天亮才醒，但是可能中途有个闹铃（信号）把你闹醒。又如：小强下午放学回家，回家了就要开始吃饭嘛，这时就会有两种情况：情况一：饭做好了，可以开始吃；情况二：当他到厨房去的时候发现妈妈还在做，妈妈就对他说：“你先去睡会，待会做好了叫你。”小强就答应去睡会，不过又说了一句：“睡的这段时间要是小红来找我玩，你可以叫醒我。”小强就是down_interruptible，想吃饭就是获取信号量，睡觉对应这里的休眠，而小红来找我玩就是中断休眠。

使用可被中断的信号量版本的意思是，万一出现了semaphore的死锁，还有机会用ctrl+c发出软中断，让等待这个内核驱动返回的用户态进程退出。而不是把整个系统都锁住了。在休眠时，能被中断信号终止，这个进程是可以接受中断信号的！比如你在命令行中输入# sleep 10000，按下ctrl + c，就给上面的进程发送了进程终止信号。信号发送给用户空间，然后通过系统调用，会把这个信号传给递给驱动。信号只能发送给用户空间，无权直接发送给内核的，那1G的内核空间，我们是无法直接去操作的。 --------------------- 本文来自 liuxd3000 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/liuxd3000/article/details/17913363?utm_source=copy