Linux Kernel源代码分析中的终极问题

        吼吼，文章名字很唬人啊。这里只是记录我在研究Linux Kernel源代码时碰到的有意思的，而目前不知道为什么的问题。

       

        * * * * *

        1）为什么Interrupt handler不能睡眠，或者更严格的说，被调度（rescheduled）

                目前引用最广泛，也最容易理解的解释是， 1）Interrupt context is time-critical because the interrupt handler interrupts the other code. Code should be quick and simple。2）Interrupt context is not associated with a process. The current macro is not relevant (although it points to the interrupted process). Without a backing process, interrupt context cannot sleep --- how would it ever reschedule?

                以我个人观点，这两条解释最多算作建议，即他建议你不要在Interrupt handler中睡眠，但你偏要睡眠他也没办法。既然kernel的scheduler会保存CPU的所有状态，从技术实现的可行性上说，应该可以对Interrupt handler进行调度，事实上只要调度被此Interrupt handler中断的process就行，即上面第二条解释的中说的current指向的与此Interrupt handler不相关的process。当然这样做会影响系统的相应速度，但这里只强调技术实现的可行性。

                这个想法应该很好验证。

          

         * * * *

         2）为什么read/write memory barrier不能保证transitivity，而general barrier可以保证

                  Documentation/memory_barriers.txt中给出的结论，不知道为什么。以我个人观点，从语义上来说read/write memory barrier应该可以保证传递性。