推 wulouise: ISR lock要等被interrupt的task unlock->可是cpu不會切 01/30 22:36
→ wulouise: 永遠等不到task unlock-> deadlock 01/30 22:36
→ saxontai: 有LinuxDev版。 01/30 22:52
→ KaiNBD: 原因如樓上，另外這主要是說明 spin_lock_irqsave 的需求 01/30 23:27
→ KaiNBD: 因 lock_irq 沒有處理 nested，導致 unlock_irq(&lock2)時 01/30 23:28
→ KaiNBD: 就立即 enable IRQ，因此進入 deadlock 狀態。 01/30 23:29
→ KaiNBD: 修正上述: 有機會進入 deadlock 狀態 01/30 23:30
→ KaiNBD: 改用 lock_irqsave 後才能在 unlock 時回復先前 IRQ 狀態 01/30 23:31
→ KaiNBD: 而非無腦啟用 IRQ。進而解決了誤啟用 IRQ 導致的 deadlock 01/30 23:32
→ gn00618777: 請問原因是我列的第一種情況嗎? ^^" 再確認一下 01/31 21:10
推 dces4212: 你這句「schedual無法再調度 02/02 19:50
→ dces4212: task使之有機會解鎖」是啥意思？沒法被排程的話，給定t 02/02 19:50
→ dces4212: ask怎麼解開原先獲得的鎖？ 02/02 19:50
→ gn00618777: 我的意思是想說第2, ISR不會霸佔CPU, OS透過schedual 02/02 21:37
→ gn00618777: 讓其他task使用CPU，只是不會給有lock的task。 02/02 21:40
→ gn00618777: 因為也是從網路上看的，我也不知道是不是第2點而造成 02/02 21:41
→ gn00618777: deadlock 02/02 21:42
推 lc85301: ISR 霸佔 CPU 的理由是，interrupt 會設定較高的優先權 02/04 10:01
推 lc85301: 優先處理，但 ISR 又卡死在搶佔 lock 的工作 02/04 10:02
推 lc85301: 時間到了 timer interrupt 跳起來，CPU 進到 scheduler 02/04 10:03
推 lc85301: scheduler 會選定優先權高的程序，也就是 ISR 繼續執行 02/04 10:04
→ gn00618777: lc大，schedual會選定優先權高的程序這句我不
太認同 02/08 21:32
→ gn00618777: 因為查了資料，ISR並不是process，也就不會被schedual 02/08 21:33
※ 編輯: gn00618777 (36.224.72.25 臺灣), 02/08/2023 21:47:28
推 lc85301: 這樣說有道理，應該說 ISR 是中斷處理，除非有權限更高的 02/08 22:42
推 lc85301: interrupt，否則它不會被 timer interrupt 打斷 02/08 22:42
推 lc85301: 所以一但 ISR 在等待某個資源解鎖，CPU 就直接卡死在那裡 02/08 22:43