无论何时你需要调度一个动作以后发生, 而不阻塞当前进程直到到时, 内核定时器是给你 的工具. 这些定时器用来调度一个函数在将来一个特定的时间执行, 基于时钟嘀哒, 并且 可用作各类任务; 例如, 当硬件无法发出中断时, 查询一个设备通过在定期的间隔内检查 它的状态. 其他的内核定时器的典型应用是关闭软驱马达或者结束另一个长期终止的操作. 在这种情况下, 延后来自 close 的返回将强加一个不必要(并且吓人的)开销在应用程序 上. 最后, 内核自身使用定时器在几个情况下, 包括实现 schedule_timeout.
一个内核定时器是一个数据结构, 它指导内核执行一个用户定义的函数使用一个用户定义 的参数在一个用户定义的时间. 这个实现位于 <linux/timer.h> 和 kernel/timer.c 并 且在"内核定时器"一节中详细介绍.
被调度运行的函数几乎确定不会在注册它们的进程在运行时运行. 它们是, 相反, 异步运 行. 直到现在, 我们在我们的例子驱动中已经做的任何事情已经在执行系统调用的进程上 下文中运行. 当一个定时器运行时, 但是, 这个调度进程可能睡眠, 可能在不同的一个处 理器上运行, 或者很可能已经一起退出.
这个异步执行类似当发生一个硬件中断时所发生的( 这在第 10 章详细讨论 ). 实际上, 内核定时器被作为一个"软件中断"的结果而实现. 当在这种原子上下文运行时, 你的代码 易受到多个限制. 定时器函数必须是原子的以所有的我们在第 1 章"自旋锁和原子上下文 "一节中曾讨论过的方式, 但是有几个附加的问题由于缺少一个进程上下文而引起的. 我 们将介绍这些限制; 在后续章节的几个地方将再次看到它们. 循环被调用因为原子上下文 的规则必须认真遵守, 否则系统会发现自己陷入大麻烦中.
为能够被执行, 多个动作需要进程上下文. 当你在进程上下文之外(即, 在中断上下文), 你必须遵守下列规则:
- 没有允许存取用户空间. 因为没有进程上下文, 没有和任何特定进程相关联的到用 户空间的途径.
- 这个 current 指针在原子态没有意义, 并且不能使用因为相关的代码没有和已被
中断的进程的联系.
- 不能进行睡眠或者调度. 原子代码不能调用 schedule 或者某种 wait_event, 也 不能调用任何其他可能睡眠的函数. 例如, 调用 kmalloc(..., GFP_KERNEL) 是违 犯规则的. 旗标也必须不能使用因为它们可能睡眠.
内核代码能够告知是否它在中断上下文中运行, 通过调用函数 in_interrupt(), 它不要 参数并且如果处理器当前在中断上下文运行就返回非零, 要么硬件中断要么软件中断.
一个和 in_interrupt() 相关的函数是 in_atomic(). 它的返回值是非零无论何时调度被 禁止; 这包含硬件和软件中断上下文以及任何持有自旋锁的时候. 在后一种情况, current 可能是有效的, 但是存取用户空间被禁止, 因为它能导致调度发生. 无论何时你 使用 in_interrupt(), 你应当真正考虑是否 in_atomic 是你实际想要的. 2 个函数都在
<asm/hardirq.h> 中声明.
内核定时器的另一个重要特性是一个任务可以注册它本身在后面时间重新运行. 这是可能 的, 因为每个 timer_list 结构在运行前从激活的定时器链表中去连接, 并且因此能够马 上在其他地方被重新连接. 尽管反复重新调度相同的任务可能表现为一个无意义的操作, 有时它是有用的. 例如, 它可用作实现对设备的查询.
也值得了解在一个 SMP 系统, 定时器函数被注册时相同的 CPU 来执行, 为在任何可能的 时候获得更好的缓存局部特性. 因此, 一个重新注册它自己的定时器一直运行在同一个 CPU.
不应当被忘记的定时器的一个重要特性是, 它们是一个潜在的竞争条件的源, 即便在一个 单处理器系统. 这是它们与其他代码异步运行的一个直接结果. 因此, 任何被定时器函数 存取的数据结构应当保护避免并发存取, 要么通过原子类型，要么使用自旋锁