(46)问题的起源:
++ 因为上面的内核代码,我们编写多线程代码时,对手里的家伙事不那么自信。但我们知道,多线程在竞争锁时,若得不到锁,会进入睡眠,并会在被唤醒后重新尝试得到锁,一直到得到了锁,线程才会继续执行下面的代码。这种线程的睡眠与唤醒机制。参考 linux 0.11 里的进程睡眠与唤醒机制。给出 linux 0.11 的源代码。
(47) 寻找 linux 0.11 的睡眠与唤醒代码:
++ 如图,在硬盘的读写过程中,对应硬盘块的内存块,是不允许被修改的。会被加锁。或者说,所有等待该内存块的进程,都会失去 CPU,被标记为 TASK_uninterruptable 状态。 进程 PCB 的 地址存储在 buffer_head . b_wait 成员里。 最后由当前操作硬盘的进程依次唤醒所有等待的线程。
(48)下图是睡眠与唤醒的原理:
(49)如下图,系统的内存缓冲区是有限的。可以接受的硬盘读写请求,也是有限的,最多 32 个,这时候,都会导致太多的进程请求去睡眠。
(50)下图里介绍了 linux 0.11 设置的进程的几种状态。区别 task_interruptable 与 task_uninterruptable 。后者不可被随便唤醒,只等待的进程来唤醒。前者可以接受信号的唤醒,比如定时器信号的唤醒。
(51) 定时睡眠的唤醒的原理支持如下。该睡眠会在进程调度时,触发进程收到一个 定时器信号 : SIGALRM 。该处于 task_interruptable 状态的进程就会 恢复运行。
(52) 那么,进程会单纯因为时间而睡眠么? 会的,下面的函数,就说明,进程会睡眠的,让出 CPU ,设置 task_struct . alarm 成员:
++ 以及:
++ 在定时中断中会维护这个定时器值。(同时下图也说明了,在 int 80H 与定时中断里,进程会响应信号量,这已经相当频繁了。):
++ 函数 do_timer ( ) 的源码:
++ 结合上图,再修正一下语言,不是在 do_timer()里完成进程的定时器逻辑。而是在 时间中断 _timer_interrrupt 里递增了全局量 jiffres 。
(53) 上面的分析,已经指出了 sleep() 睡眠,触发的信号量 SIGALRM 。那么进程如何进入 task_interruptable 状态呢?因为没有 sleep() 函数的源代码。但是知道 waitpid () 函数,也会使进程自身睡眠,并也进入 task_interruptable 状态:
++ 以及 wait_pid()。该函数里有对进程状态的设置:
(54) 以上关于定时睡眠的理论分析,基于 linux 0.11 。但也适用于,可以为现代的 C++ STL 库中的条件变量 conditon_variable 提供指导, cv 包含了关于时间的成员函数。举例如下::
++ 上图引用了模糊的内核函数 ,_Cnd_timedwait (…) ,因为没有其源代码,不清楚锁与定时睡眠引起的线程唤醒与睡眠的关系,才引出了本文的推导与求证,试图自圆其说,更接近一些真相。核心问题就是:线程没育抢到锁的时候,还会醒来么?加了定时睡眠呢?醒来后代码流程还会继续么? unique_lock 在析构时候,如何处理锁呢?。
(55)通过以上的分析,得出的结论是** 定时睡眠,使进程进入了可中断睡眠状态。到时后会因为信号 SIGALRM 被唤醒,恢复进程的执行**。而在 linux 里,认为线程是轻量级的进程,这里试图类比线程为进程来理解线程。
(56)对于现代的 c++ STL 库里引起的代码逻辑,只可以用测试,来感觉里面的涉及操作系统的信号的,锁的,条件变量的代码逻辑。 先给出第一版,这是最正确的,最简单的一版,随后再修改和复杂其中的逻辑:
++ 以及:
++ 以及:
++ 以及:
++ 作为强烈对比:把上面的锁 mutex 换成 timed_mutex 就会得出完全不一样的结果,代码逻辑不变:
++ 正是为了解释此问题,引出了本篇文章与下一篇文章。
(57) 补充 cv 的函数特性:
(58) 这俩图还搬过来:
++ 以及:
(59)继续分析为什么定时 mutex 可以准确的依据时间。先给出一个图:
(60)
谢谢