[ThreadX, 2] conception and terms

Priority

• 有靜態與動態，簡單的說就是執行的過程中是否修改priority
• 0~31: 0最高

Ready & suspend

• ready: 隨時可以執行(但其他更高優先全的thread占著CPU)
• suspend: 由於某種原因(等待資原，被高優先權thread搶占，other OS　service)被掛起
• 相關流程:thread -> put it into suspend list

 -> remove it from suspend list and put it into ready list

 -> remove it from ready list(FIFO) and run it(假設大家優先全都一樣等最久的先執行)

scheduling

• preemptive: 高優先權thread可以中段並掛起當前正在執行的低優先權thread
• round-robin: 相同優先權的thread該如何分享CPU，有兩種方式:
• 每個threa都執行N個tick(time slice)
• 正在執行的thread放棄執行(cooperative multithreading)，使其他相同或更高優先權的可拿到CPU並將自己放在ready list(FIFO)

context switch

• context是thread當前的執行狀態(PC, SP, registers)
• context switch是指thread交換(包含ISR)時，context的save與restore。

starvation

• CPU被高優先權的thread占去大多的時間導致低優先權的沒機會執行。

priority inversion

• Bounded priority inversion
• 高優先權的process/thread等待進入critical section，該critical section目前由低優先權的process/thread佔用中。
• 因此只要低優先權的process/thread離開該critical section後高優先權的process/thread便可繼續執行
• Unbounded priority inversion
• 高優先權的process/thread等待進入critical section，該critical section目前由低優先權的process/thread佔用中
• 不幸的是，當低優先權process/thread還在critical section執行的時候，被切換到中優先權的process/thread由於高優先權的process/thread被block，而低優先權的process/thread一定會被中優先權的process/thread搶走執行權。該resource 也就一直被拿著但也不處理，最壞的狀況就是之後就只剩中優先權的process/thread被執行
• 解法:
• mutex's priority inheritance option.
• priority threshold to avoid preempted by thread2.

priority inheritance (threadX only)

• mutex的ㄧ個選項，允許poiority低的thread暫時以等待其釋放資源的高優先權thread的priority執行，來避免priority inversion。

Priority inheritance allows a lower-priority thread to temporarily assume the priority of a

higher-priority thread that is waiting for a mutex owned by the lower-priority thread.

This capability helps the application to avoid nondeterministic priority inversion by

eliminating preemption of intermediate thread priorities. The mutex is the only ThreadX

resource that supports priority inheritance.

Preemption-threshold(threadX only)

• 創建thread時設閥值，當其他thread要強佔時，priority需高於(不包含)此閥值。
• disable的話則與priority設一樣的值即可。
• 注意會使thread的time-slice屬性無效。
• 當priority有做調整時此屬性會被設disable

semaphore && mutex

• 比較表:
• 
• 相對於 mutex，semaphre沒有所有權的概念，也就是說可以由其他的thread來put。
• mutex才有優先權繼承的service。
• mutex較健壯如果，對互斥很重是可以選擇此；但如果不是，semaphore稍快。 同步的處理中常會用到，Wait forever選項，但在即時的函式中只能改為no wait，如ISR, Timer

同步的OS service有mutex/semaphore/event/queeu，其有些共同特色:

• FIFO: 被掛起的thread，當條件滿足時，先被resume的不是priority最高的(除非操作特定API 將最高priority的thread 放到FIFO 前)而是等最久的；Event是個例外，當TX_OR set時是所有被掛起的thread都檢查一次。
• delete: 做刪除動作時，所有被suspend的thread會resume並返回TX_DELETE。

• OS service suggestion:
• 

Questions:

• Guess the purpose of following code

sp5kOsMutexGet(&GPSGSVmutex, TX_WAIT_FOREVER);
sp5kOsMutexPut(&GPSGSVmutex);

Ans:

1. 框一個critcial section，保護resouce(全域變數,  HW resource, Function…)，

該區間只允許一個thread 進入。

    2.     兩個放在一起。拿來與其他thread sync用(只是個同步點?)，其他的Thread要put完(mutex初始直為0)，此Thread才能往下走。

• while ( ros_semaphore_put(mediaCb.sigDisp) == SUCCESS ) {

ros_semaphore_get(mediaCb.sigDisp, ROS_WAIT_FOREVER);

• semaphore 會根據掛起的先後順序(FIFO)來決定誰去get到下一個，所以這段code可以用來允許被abort( abort/resume => get/put於其他task())，因為PUT完下面那一行不一定會GET到。

=>可用於暫停功能，例如host呼叫暫停(get semaphore)，則此迴圈跑完就會因為拿不到，semaphore而被暫停。

• Replacing following mutex with critical section makes it better or worse? Why?

sp5kOsMutexGet(&vidurgmut, TX_WAIT_FOREVER);
urgentCbCnt--;
sp5kOsMutexPut(&vidurgmut);

Ans: Depend on CPU(single or multi)//雖然此cretical section夠短

       1. MUTEX 需要額外消耗資源如MCB( mutex control block)，context switch等。critical section(disable interrupt)，較低階(設個暫存器而已)_，所花的時間與資源相對少很多。

       2. 但是~~~假設ＣＰＵ不只一個，那麼就無法用取消中斷(Enter Critical)的方式來達成，因為若要達成同樣目的，要取消所有ＣＰＵ的中斷，效能不好(要發disable interrupt給所有cpu, 等所有cpu回覆我已中斷，才能執行)，用ＭＵＴＥＸ就不會有此問題。

• ISR(非同步事件)
• 當ISR發生時，原本的task就會被搶占(且做contex switch)，當ISR完成後，就會察看ready list換誰了。