在等待隊列上放置進程時發生中斷

Question

假設有一個進程嘗試進入關鍵區域，但由於它被其他進程佔用，當前進程必須等待它。所以，當進程被添加到信號量的等待隊列中時，假設有一箇中斷（電池完成），那麼該進程和等待隊列會發生什麼？

我認爲，由於電池已經完成所以這個中斷將具有最高優先級，因此這是放置過程中的等待隊列中的進程上下文將被保存和中斷服務例程該路由將是執行。

然後它將返回到將進程放入隊列的進程。

請給這個問題一些提示/建議。

Answer 1

它取決於實現，但從概念上講，相同的操作過程應執行將等待隊列添加到中斷和管理中斷的過程，因此，等待的過程將被視爲中斷等待隊列。

對於Java，請參閱API爲Thread.interrupt()

中斷該線程。

除非當前線程正在中斷自己，而這總是被允許的，否則會調用此線程的checkAccess方法，這可能會導致拋出SecurityException。

如果該線程被阻塞在等待的調用（），等待（長），或者等待Object類（長，INT）的方法，或的連接（），加入（長），加入（long，int），睡眠（long）或睡眠（long，int）這個類的方法，然後它的中斷狀態將被清除並且它將收到一個InterruptedException。

如果此線程在可中斷通道的I/O操作中被阻塞，則通道將被關閉，線程的中斷狀態將被設置，並且線程將收到ClosedByInterruptException。

如果此線程在選擇器中被阻塞，那麼線程的中斷狀態將被設置，並且它將立即從選擇操作中返回，可能具有非零值，就像調用選擇器的喚醒方法一樣。

如果前面的條件都不成立，那麼該線程的中斷狀態將被設置。

中斷不活動的線程不需要任何影響。

Answer 2

這是非常硬件/操作系統有關，但一些想法：

正如在評論中已經提到的，「電池成品」中斷可以被視爲一個特殊的情況下，僅僅是因爲機器可能在不採取任何行動的情況下關閉，在這種情況下，進程+隊列將消失。但是，通常情況下，假設一個非致命中斷和一個正確掛起/恢復的操作系統，我認爲這對任何一個進程的執行都不會有明顯的影響。

在多核設置中，該過程可能不會立即掛起。中斷可以由不同的內核來處理，你所提到的任何過程都不會更聰明。

在搶先式多任務操作系統中，也不能保證在中斷之後立即恢復加入隊列的進程，調度程序可以決定完全激活當前在臨界區或其他進程中的進程。當信號量等待隊列重新啓動時，會發生什麼情況將取決於添加信號的程度，隊列的實現方式以及信號量的狀態。它可能永遠不會進入等待隊列因爲它檢測到另一個進程已經醒來並離開關鍵部分，或者它可能完成將其自身添加到隊列並暫停，就好像什麼也沒有發生一樣......

在一個單核/處理器機器合作性多任務操作系統，我認爲你在問題中描述的場景很可能是，執行的進程被暫停以處理中斷，然後重新開始，直到完成將其添加到隊列並放棄爲止。