阻塞与非阻塞 定时器 工作队列 中断的线程化处理 mmap

阻塞与非阻塞

所谓阻塞，就是等待某件事情发生。比如调用 read 读取按键时，如果没有按键数据则 read 函数不会返
回，它会让线程休眠等待。
使用 poll 时，如果传入的超时时间不为 0，这种访问方法也是阻塞的。
使用 poll 时，可以设置超时时间为 0，这样即使没有数据它也会立刻返回，这就是非阻塞方式。能不
能让 read 函数既能工作于阻塞方式，也可以工作于非阻塞方式？可以！
APP 调用 open 函数时，传入 O_NONBLOCK，就表示要使用非阻塞方式；默认是阻塞方式。
注意：对于普通文件、块设备文件，O_NONBLOCK 不起作用。
注意：对于字符设备文件，O_NONBLOCK 起作用的前提是驱动程序针对 O_NONBLOCK 做了处理。
只能在 open 时表明 O_NONBLOCK 吗？在 open 之后，也可以通过 fcntl 修改为阻塞或非阻塞。

应用编程

open 时设置：
int fd = open(“/dev/xxx”, O_RDWR | O_NONBLOCK); /* 非阻塞方式 */
int fd = open(“/dev/xxx”, O_RDWR ); /* 阻塞方式 */
open 之后设置：
int flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, flags | O_NONBLOCK); /* 非阻塞方式 */
fcntl(fd, F_SETFL, flags & ~O_NONBLOCK); /* 阻塞方式 */

驱动编程

以 drv_read 为例：
static ssize_t drv_read(struct file *fp, char __user *buf, size_t count, loff_t *ppos)
｛ 
if (queue_empty(&as->queue) && fp->f_flags & O_NONBLOCK)
return -EAGAIN;
wait_event_interruptible(apm_waitqueue, !queue_empty(&as->queue));
……
｝

从驱动代码也可以看出来，当 APP 打开某个驱动时，在内核中会有一个 struct file 结构体对应这个
驱动，这个结构体中有 f_flags，就是打开文件时的标记位；可以设置 f_flasgs 的 O_NONBLOCK 位，表示非
阻塞；也可以清除这个位表示阻塞。
驱动程序要根据这个标记位决定事件未就绪时是休眠和还是立刻返回

驱动程序程序“只提供功能，不提供策略”。就是说驱动程序可以提供休眠唤醒、查询等等各种方式，驱动程序只提供这些能力，怎么用由 APP 决定。

定时器

内核函数
所谓定时器，就是闹钟，时间到后你就要做某些事。有 2 个要素：时间、做事，换成程序员的话就是：
超时时间、函数。
在内核中使用定时器很简单，涉及这些函数(参考内核源码 include\linux\timer.h)：
① setup_timer(timer, fn, data)：
设置定时器，主要是初始化 timer_list 结构体，设置其中的函数、参数。
② void add_timer(struct timer_list *timer)：
向内核添加定时器。timer->expires 表示超时时间。
当超时时间到达，内核就会调用这个函数：timer->function(timer->data)。
③ int mod_timer(struct timer_list *timer, unsigned long expires):
修改定时器的超时时间，
它等同于：del_timer(timer); timer->expires = expires; add_timer(timer);
但是更加高效。
④ int del_timer(struct timer_list *timer)：
删除定时器。

定时器时间单位
编译内核时，可以在内核源码根目录下用“ls -a”看到一个隐藏文件，它就是内核配置文件。打开后
可以看到如下这项：
CONFIG_HZ=100
这表示内核每秒中会发生 100 次系统滴答中断(tick)，这就像人类的心跳一样，这是 Linux 系统的心
跳。每发生一次 tick 中断，全局变量 jiffies 就会累加 1。
CONFIG_HZ=100 表示每个滴答是 10ms。
定时器的时间就是基于 jiffies 的，我们修改超时时间时，一般使用这 2 种方法：
① 在 add_timer 之前，直接修改：
timer.expires = jiffies + xxx; // xxx 表示多少个滴答后超时，也就是 xxx10ms
timer.expires = jiffies + 2HZ; // HZ 等于 CONFIG_HZ，2HZ 就相当于 2 秒
② 在 add_timer 之后，使用 mod_timer 修改：
mod_timer(&timer, jiffies + xxx); // xxx 表示多少个滴答后超时，也就是 xxx10ms
mod_timer(&timer, jiffies + 2HZ); // HZ 等于 CONFIG_HZ，2HZ 就相当于 2 秒

中断下半部 tasklet
中断的处理有几个原则：
① 不能嵌套；
② 越快越好。
在处理当前中断时，即使发生了其他中断，其他中断也不会得到处理，所以中断的处理要越快越好。但
是某些中断要做的事情稍微耗时，这时可以把中断拆分为上半部、下半部。
在上半部处理紧急的事情，在上半部的处理过程中，中断是被禁止的；
在下半部处理耗时的事情，在下半部的处理过程中，中断是使能的。

工作队列

前面讲的定时器、下半部 tasklet，它们都是在中断上下文中执行，它们无法休眠。当要处理更复杂的事情时，往往更耗时。这些更耗时的工作放在定时器或是下半部中，会使得系统很卡；并且循环等待某件事情完成也太浪费 CPU 资源了。
如果使用线程来处理这些耗时的工作，那就可以解决系统卡顿的问题：因为线程可以休眠。
在内核中，我们并不需要自己去创建线程，可以使用“工作队列(workqueue)。内核初始化工作队列是，就为它创建了内核线程。以后我们要使用“工作队列”，只需要把“工作”放入“工作队列中”，对应的
内核线程就会取出“工作”，执行里面的函数。在 2.xx 的内核中，工作队列的内部机制比较简单；在现在 4.x 的内核中，工作队列的内部机制做得复
杂无比，但是用法是一样的。工作队列的应用场合：要做的事情比较耗时，甚至可能需要休眠，那么可以使用工作队列。
缺点：多个工作(函数)是在某个内核线程中依序执行的，前面函数执行很慢，就会影响到后面的函数。在多 CPU 的系统下，一个工作队列可以有多个内核线程，可以在一定程度上缓解这个问题。

使用工作队列时，步骤如下：
① 构造一个 work_struct 结构体，里面有函数；
② 把这个 work_struct 结构体放入工作队列，内核线程就会运行 work 中的函数
3.调用 schedule_work 时，就会把 work_struct 结构体放入队列中，并唤醒对应的内核线程。内核线程就
会从队列里把 work_struct 结构体取出来，执行里面的函数

中断的线程化处理

复杂、耗时的事情，尽量使用内核线程来处理。上节视频介绍的工作队列用起来挺简单，但是它有一个缺点：工作队列中有多个 work，前一个 work 没处理完会影响后面的 work。解决方法有很多种，比如干脆自己创建一个内核线程，不跟别的 work 凑在一块了。在 Linux 系统中，对于存储设备比如 SD/TF 卡，它的驱动程序就是这样做的，它有自己的内核线程。
对于中断处理，还有另一种方法： threaded irq，线程化的中断处理。中断的处理仍然可以认为分为上半部、下半部。上半部用来处理紧急的事情，下半部用一个内核线程来处理，这个内核线程专用于这个中断

你可以只提供 thread_fn，系统会为这个函数创建一个内核线程。发生中断时，系统会立刻调用 handler函数，然后唤醒某个内核线程，内核线程再来执行 thread_fn 函数。

mmap

应用程序和驱动程序之间传递数据时，可以通过 read、write 函数进行。这涉及在用户态 buffer 和内核态 buffer 之间传数据，如下图所示：

应用程序不能直接读写驱动程序中的 buffer，需要在用户态 buffer 和内核态 buffer 之间进行一次数据拷贝。这种方式在数据量比较小时没什么问题；但是数据量比较大时效率就太低了。比如更新 LCD 显示时，如果每次都让 APP 传递一帧数据给内核，假设 LCD 采用 102460032bpp 的格式，一帧数据就有102460032/8=2.3MB 左右，这无法忍受。
改进的方法就是让程序可以直接读写驱动程序中的 buffer，这可以通过 mmap 实现(memory map)，把内核的 buffer 映射到用户态，让 APP 在用户态直接读写。