（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）

谢谢