5.5.2. 自旋锁和原子上下文
“想象一会儿你的驱动请求一个自旋锁并且在它的临界区里做它的事情. 在中间某处, 你的驱动失去了处理器. 或许它已调用了一个函数( copy_from_user, 假设) 使进程进入睡眠. 或者, 也许, 内核抢占发威, 一个更高优先级的进程将你的代码推到一边. 你的代码现在持有一个锁, 在可见的将来的如何时间不会释放这个锁. 如果某个别的线程想获得同一个锁, 它会, 在最好的情况下, 等待( 在处理器中自旋 )很长时间. 最坏的情况, 系统可能完全死锁.”
此情景即：持有锁的进程睡眠后，别的线程想获得这个锁。
“这有另一个场景: 你的驱动在执行并且已经获取了一个锁来控制对它的设备的存取. 当持有这个锁时, 设备发出一个中断, 使得你的中断处理运行. 中断处理, 在存取设备之前, 必须获得锁. 在一个中断处理中获取一个自旋锁是一个要做的合法的事情; 这是自旋锁操作不能睡眠的其中一个理由. 但是如果中断处理和起初获得锁的代码在同一个处理器上会发生什么? 当中断处理在自旋, 非中断代码不能运行来释放锁. 这个处理器将永远自旋.”
此情景是这样的：产生中断的进程所等待的锁就是被这个中断打断的进程所持有的锁。
“当你编写你的代码, 你会毫无疑问遇到几个函数需要存取通过一个特定锁保护的结构. 在此, 你必须小心: 如果一个函数需要一个锁并且接着调用另一个函数也试图请求这个锁, 你的代码死锁. 不论旗标还是自旋锁都不允许一个持锁者第 2 次请求锁; 如果你试图这样做, 事情就简单地完了.”
即：持锁代码内部请求这个锁
“在有大量锁的系统中(并且内核在成为这样一个系统), 一次需要持有多于一个锁, 对代码是不寻常的. 如果某类计算必须使用 2 个不同的资源进行, 每个有它自己的锁, 常常没有选择只能获取 2 个锁.
获得多个锁可能是危险的, 然而. 如果你有 2 个锁, 称为 Lock1 和 Lock2, 代码需要同时都获取, 你有一个潜在的死锁. 仅仅想象一个线程锁住 Lock1 而另一个同时获得 Lock2. 接着每个线程试图得到它没有的那个. 2 个线程都会死锁.”
即：线程A和线程B都需要LOCK1 和 LOCK2，若他们同时请求，且A获得了lock1，B获得了lock2，则他们都死锁。
6.1 选择ioctl命令
“多数程序员本能反应是从0或1开始选择一组小的编号。。。有许多理由不能这样，为了防止对错误的设备使用正确的命令，命令号应该在系统范围内唯一。”
从0或1开始选择一组小的编号的意思是：比如用0-100表示100种操作，对设备A使用这100种，对设备B也使用这100种。产生的后果就是，如果对一个设备使用了不符合它的操作，程序并不能判断出来。而如果对系统（而不是对设备）的每一个操作都唯一，那么，只要有定义的操作就是合法的，未定义的操作就是非法的。详见Ioctl-number.txt