優先順序反轉問題
所謂優先順序翻轉問題(priority inversion)即當乙個高優先順序任務通過
訊號量機制訪問共享資源時，該訊號量已被一低優先順序任務占有，而這個低優先順序任務在訪問共享資源時可能又被其它一些中等優先順序任務搶先，因此造成高優先順序任務被許多具有較低優先順序任務阻塞，實時性難以得到保證。
例如：有優先順序為a、b和c三個任務，優先順序a>b>c，任務a，b處於
掛起狀態，等待某一事件發生，任務c正在執行，此時任務c開始使用某一共享資源s。在使用中，任務a等待事件到來，任務a轉為就緒態，因為它比任務c優先順序高，所以立即執行。當任務a要使用共享資源s時，由於其正在被任務c使用，因此任務a被掛起，任務c開始執行。如果此時任務b等待事件到來，則任務b轉為就緒態。由於任務b優先順序比任務c高，因此任務b開始執行，直到其執行完畢，任務c才開始執行。直到任務c釋放共享資源s後，任務a才得以執行。在這種情況下，優先順序發生了翻轉，任務b先於任務a執行。
解決優先順序翻轉問題有優先順序天花板(priority ceiling)和優先順序繼承(priority inheritance)兩種辦法。
優先順序天花板是當任務申請某資源時， 把該任務的優先順序提公升到可訪問這個資源的所有任務中的最高優先順序， 這個優先順序稱為該資源的優先順序天花板。這種方法簡單易行， 不必進行複雜的判斷， 不管任務是否阻塞了高優先順序任務的執行， 只要任務訪問共享資源都會提公升任務的優先順序。
優先順序繼承是當任務a 申請共享資源s 時， 如果s正在被任務c 使用，通過比較任務c 與自身的優先順序，如發現任務c 的優先順序小於自身的優先順序， 則將任務c的優先順序提公升到自身的優先順序， 任務c 釋放資源s 後，再恢復任務c 的原優先順序。這種方法只在占有資源的低優先順序任務阻塞了高優先順序任務時才動態的改變任務的優先順序，如果過程較複雜， 則需要進行判斷。
附加方法：
第三種方法就是使用中斷禁止，通過禁止中斷來保護臨界區，採用此種策略的系統只有兩種優先順序：可搶占優先順序和中斷禁止優先順序。前者為一般程序執行時的優先順序，後者為執行於臨界區的優先順序。火星探路者正是由於在臨界區中執行的氣象任務被中斷發生的通訊任務所搶占才導致故障，如果有臨界區的禁止中斷保護，此一問題也不會發生。
這裡還有乙個八卦，2023年的美國的火星探測器（使用的就是vxworks)就遇到乙個優先順序反轉問題引起的故障。簡單說下，火星探測器有乙個資訊匯流排，有乙個高優先順序的匯流排任務負責匯流排資料的訪問，訪問匯流排都需要通過乙個互斥鎖（共享資源出現了）；還有乙個低優先順序的，執行不是很頻繁的氣象蒐集任務，它需要對匯流排寫資料，也就同樣需要訪問互斥鎖；最後還有乙個中優先順序的通訊任務，它的執行時間比較長。平常這個系統執行毫無問題，但是有一天，在氣象任務獲得互斥鎖往匯流排寫資料的時候，乙個中斷發生導致通訊任務被排程就緒，通訊任務搶占了低優先順序的氣象任務，而無巧不成書的是，此時高優先順序的匯流排任務正在等待氣象任務寫完資料歸還互斥鎖，但是由於通訊任務搶占了cpu並且執行時間比較長，導致氣象任務得不到cpu時間也無法釋放互斥鎖，本來是高優先順序的匯流排任務也無法執行，匯流排任務無法及時執行的後果被探路者認為是乙個嚴重錯誤，最後就是整個系統被重啟。vxworks允許優先順序繼承，然而遺憾的工程師們將這個選項關閉了。
知識點總結》隨筆
目錄 小知識點總結 mysql 中 in 和 exists 的區別 如果查詢的兩個表大小相當，那麼用in和exists差別不大。如果兩個表中乙個較小，乙個是大表，則子查詢表大的用exists，子查詢錶小的用in 例如 表a 小表 表b 大表 1 select from a where cc in s...
android知識點隨筆
android project中manifest.xml中的標籤元素決定的。此標籤包含如下3個屬性 android minsdkversion 此屬性決定你的應用能相容的最低的系統版本，一盤情況是必須設定此屬性。android targetsdkversion 此屬性說明你當前的應用是針對某乙個系統...
執行緒知識點
1.join 執行緒a 呼叫了 執行緒b 的 join 方法 執行緒a 必須等待執行緒b 執行完後 才能執行 2.yield sleep wait notify 釋放鎖問題 呼叫yield sleep 執行緒 持有的鎖 不釋放 wait 呼叫方法前 必須持有鎖，呼叫之後釋放鎖，wait 返回後持有鎖...