將val_a、val_b以及val_fa等局部變量定義為靜態(tài)變量（加上static指示符）可以解決這一問題。但問題是，定義大量的static類型變量，將導(dǎo)致RAM空間的大量占用，有可能直接導(dǎo)致RAM空間不夠用。尤其是在一些小容量的單片機內(nèi)，一般只有 128或256字節(jié)，大量的靜態(tài)變量定義，在如此小的RAM資源狀況下顯然就不太合適了。由此而有了另一種的解決方法，如下代碼所示：

　　void TaskC（void）{

　　UINT8 x，v;

　　whlk（1）{

　　OS_ENTER_CRITICAL（）;

　　x=GetX（）; （1）

　　y=GetY（）; （2）

　?。蝿?wù)的其他代碼

　　OS_EXIT_CRITICAL（）; （3）

　　0SSleep（100）; （4）

　　}

　　}

　　以上代碼TaskC中使用了臨界保護的方法來保護代碼不被中斷占先，確實有效地解決了RAM空間太小，不宜大量定義靜態(tài)變量的問題。然而如果每個任務(wù)都采用此種結(jié)構(gòu)，任務(wù)一開始，就關(guān)閉中斷，將使實時性得不到保證。事實證明，這種延時是相當可觀的。用一個實例來說明，如果想在系統(tǒng)中使用一個動態(tài)刷新的LED 顯示器，就難以保證顯示的穩(wěn)定與連續(xù)，哪怕在系統(tǒng)中是使用一個單獨的定時器來做這一工作（進入臨界區(qū)后，EA=0）。其次，這種結(jié)構(gòu)事實上將占先的任務(wù)調(diào)度轉(zhuǎn)化為非占先的任務(wù)調(diào)度。實際上如果在（3）與（4）之間沒有碰巧發(fā)生中斷并導(dǎo)致一個任務(wù)調(diào)度，那就可以理解為是任務(wù)主動放棄CPU的控制。如果在（3）和（4）之間碰巧產(chǎn)生了一個中斷并導(dǎo)致了一個任務(wù)調(diào)度，只是執(zhí)行了一次多余的任務(wù)調(diào)度而已，而且并不希望在（3）之后發(fā)生2次甚至多次的任務(wù)調(diào)度，相信讀者也有這一愿望。

　　除此之外，還可以發(fā)現(xiàn)任務(wù)的一個特點：當任務(wù)從（1）重新開始時，局部變量x和y是一個什么值并不在乎，即x和y 即使在（3）之后改變了，也已經(jīng)不再重要，不會影響程序的正確性。其實這一特點也是大部分任務(wù)，至少是太部分任務(wù)的大部分局部變量的一個共性——如果任務(wù)在整個執(zhí)行過程中，不會（被占先）放棄CPU控制權(quán)，則其局部變量大多數(shù)并不需要進行特別的保護，即其作用域只是任務(wù)的當次執(zhí)行，針對上面的代碼，就是臨界保護區(qū)內(nèi)的代碼區(qū)域。

　　2 實時操作系統(tǒng)要不要占先

　　由上面的分析，如果要保持一個函數(shù)可重人，就得使用靜態(tài)變量，系統(tǒng)的RAM資源將是一個嚴峻的考驗;如果使用臨界區(qū)來保護運行環(huán)境，系統(tǒng)的實時性又得不到保證，而且有將占先式任務(wù)調(diào)度轉(zhuǎn)為非占先任務(wù)調(diào)度之虞。顯然，使用靜態(tài)變量簡單，但有更多的不適用性，對將來功能的調(diào)整也是一個阻礙，一般不被采用。那么，就只能從環(huán)境保護上來下功夫了，但是果真只能以進入臨界區(qū)犧牲系統(tǒng)的實時性來保證任務(wù)不被占先？下面看看臨界保護這一方法的基本思路：

　?、僭谝粋€任務(wù)中，如果局部變量在其作用域內(nèi)不被占先切換，則這些變量在任務(wù)被剝奪了CPU控制權(quán)后，不關(guān)心其值也不會影響任務(wù)的正確執(zhí)行;

　?、谑褂门R界區(qū)保護，可以達到上面所提到的要求;

　?、塾纱藢?dǎo)致的實時性能與占先切換的減弱可以接受。由此可知，不被占先是任務(wù)保護局部變量的關(guān)鍵。既然如此，何不舍棄占先式的任務(wù)調(diào)度？這不失為一個好的出發(fā)點。針對Keil C51，非占先式任務(wù)調(diào)度，可能是一種更好的方法，更能協(xié)調(diào)51系列單片機的既定資源。下面編寫這樣一個系統(tǒng)：

　?、偈褂梅钦枷仁饺蝿?wù)調(diào)度;

　?、诳梢栽谛∪萘康男酒惺褂茫_發(fā)目標是，即使是8051這樣小的芯片，也可使用這個實時操作系統(tǒng);

　?、壑С謨?yōu)先級調(diào)度，盡可能保證其實時性。