ucos ii 任務的刪除

建立任務的過程，首先分配乙個空閒的tcb給任務，然後對該tcb的各個域進行賦值，對任務的堆疊進行初始化，其中，任務的**的位址被壓入堆疊。這為以後任務的執行做了充分準備。就緒表和就緒組做了適當的處理，根據任務的優先順序進行了設定。就緒tcb鍊錶也插入了該tcb。

那麼若將任務刪除，就是任務建立的逆過程，應該將就緒表、就緒組進行逆向操作，就緒鍊錶中的相關tcb應該被移除，轉移到空閒tcb鍊錶。和任務建立一樣，也要進行一些檢查，看任務是否符合被刪除的條件。

任務刪除還設計乙個請求刪除的問題，因此任務刪除看似簡單，實際上是比較複雜的乙個過程。

任務刪除函式的引數只有乙個，這個引數就是任務的優先順序。我們知道，任務的優先順序是μc/os-ii標誌任務的唯一標誌，任務控制塊中雖然也有乙個id，但只是為了擴充套件使用。因此，任務刪除函式也可以理解為刪除指定優先順序的任務。

由於任務刪除的**很長，而在執行的過程中一直在訪問全域性變數，因此使系統不能響應中斷，破壞系統的實時性。因此，在**的中間，使用巧妙的手段來開一次中斷，過程如下：

1）將任務排程鎖加1

2）開中斷

3）執行一條空語句保證中斷有時間執行

4）關中斷

5）將排程鎖減1，恢復原來的值。

這一段**幾乎是μc/os-ii中最複雜的一段**，理解它需要有足夠的耐心。

當以其他任務的優先順序作為引數的時候，ostaskdel粗暴地刪除了任務，這在某些情況下是有效的，但是卻不是必須這麼做。通知對方任務，告訴它要被刪除了，請任務自己刪除自己是一種更好的做法。因為這麼做，任務可以在刪除自己之前先放棄自己使用的資源，如緩衝區、訊號量、郵箱、佇列等。如果總是用

ostaskdel刪除乙個任務，這個任務占用的資源不能得到釋放，系統就會產生記憶體洩露，在記憶體洩露累積到比較大的時候，系統就會因為沒有可用的記憶體而崩潰。

其實ostaskdelreq名稱雖然是請求，卻是集請求與響應於一段**內，改**的功能時請求刪除某任務和檢視是否有任務要刪除自己。

例如，優先順序為5的任務a呼叫

ostaskdelreq

(10)，請求刪除優先順序為10的任務b。任務b呼叫

ostaskdelreq(os_prio_sel)並檢視返回值，如果返回值為os_err_task_del_req，說明有任務要刪除自己了。任務b應該先釋放自己使用的資源，然後呼叫

ostaskdel(10)或

ostaskdel(

os_prio_sel

)來刪除自己。