- 論壇徽章:
- 0
|
一直認(rèn)為中斷處理函數(shù)不能休眠的是天經(jīng)地義的,可從沒認(rèn)真思考過問什么不能休眠,阻塞。最近看了一下ulk中對(duì)這個(gè)的解釋,感覺還是有點(diǎn)不太明白,
“The price to pay for allowing nested kernel control paths is that an interrupt handler must never block, that is, no process switch can take place until an interrupt handler is running. In fact, all the data needed to resume a nested kernel control path is stored in the Kernel Mode stack, which is tightly bound to the current process.”
上面把中斷處理程序不能休眠歸結(jié)為中斷處理程序可以嵌套,而恢復(fù)嵌套的中斷處理程序的相關(guān)數(shù)據(jù)放在內(nèi)核態(tài)堆棧中,這個(gè)棧和當(dāng)前進(jìn)程相關(guān)聯(lián),這里有一點(diǎn)不明白,既然有棧存儲(chǔ)數(shù)據(jù),而且進(jìn)程切換出去后,這個(gè)棧也不會(huì)被銷毀,等進(jìn)程在切回來時(shí),不同樣可以是嵌套的中斷處理程序返回嗎?(這里先不考了中斷處理時(shí)間的太長,影響對(duì)中斷處理的服務(wù)問題,只說明中斷是否可休眠)。同時(shí)我google一下,看到有人對(duì)中斷不能休眠的以一種解釋:
”
中斷處理程序用到的所有數(shù)據(jù)有保存在當(dāng)前進(jìn)程的內(nèi)核堆棧中(一般情況下),如果此時(shí)發(fā)生了
進(jìn)程切換,中斷處理程序?qū)⒈蛔枞?當(dāng)在一次發(fā)生進(jìn)程切換時(shí),不一定馬上就換回來。比如當(dāng)
發(fā)生一個(gè)鍵盤中斷時(shí),鍵盤處理程序正在進(jìn)行,此時(shí)又恰好發(fā)生了進(jìn)程搶占,切換到了另一個(gè)進(jìn)程
中,假如那個(gè)進(jìn)程不會(huì)引起內(nèi)核的穩(wěn)定,那么中斷處理程序?qū)⒁恢弊枞瑑?nèi)禾根本就沒法響應(yīng)那個(gè)中斷,
直到在一次發(fā)生進(jìn)程切換。假設(shè)最后又切換回執(zhí)行中斷處理程序的那個(gè)進(jìn)程中時(shí),如果它的內(nèi)核堆棧
受到了無意的破壞怎么辦呢?那中斷處理程序可能無法在繼續(xù)運(yùn)行下去了,此次中斷服務(wù)失敗。而且
現(xiàn)在的處理程序都允許中斷嵌套,一個(gè)中斷被阻塞,其它的都將被阻塞。所以面對(duì)錯(cuò)綜復(fù)雜的內(nèi)核邏輯,
最好的辦法就是在中斷處理程序中禁止發(fā)生進(jìn)程切換,這樣既提高了中斷處理程序的響應(yīng)速度,也增加了
內(nèi)核的穩(wěn)定性與安全性。
“
我感覺他的理由有兩個(gè):一個(gè)事效率,可能影響處理速度,另一就是:如果它的內(nèi)核堆棧
受到了無意的破壞怎么辦?
對(duì)于第一種理由先不討論,
可第二種,理由我感覺很牽強(qiáng),如果棧那么容易破壞,哪我也可以說描述進(jìn)程的數(shù)據(jù)結(jié)構(gòu)什么的也可能被破壞,哪豈不是進(jìn)程調(diào)度都是不安全的了,
這樣按他的說法,就只有第一個(gè)效率的原因了。
回到ulk的解釋,不知道是不是我理解的有問題,The price to pay for allowing nested kernel control paths is that an interrupt handler must never block
感覺他把中端不能休眠的原因都?xì)w結(jié)為可支持中斷處理程序的嵌套上了。那是不是可以這樣理解,如果不支持中斷嵌套,中斷處理程序就可以休眠了,呵呵呵,貌似這樣也不對(duì)吧,
問題:中斷處理程序不能休眠的原因究竟是什么呢? |
|