small rtos5l是一款專門為80c5l系列單片機設計的實時操作系統(tǒng)(實際上應該稱其為實時內(nèi)核)，大部分代碼用c語言編寫，易于移植，十分適合于資源緊張的8位機。同時，它也是學習嵌入式操作系統(tǒng)原理極好的入門材料。本人就是在學習完smallrtos5l的基礎上進一步學習了著名的uc／0s-ii，受益頗多。 　　1 問題描述 　　在將smau rtos51應用于實驗室某項目時，發(fā)現(xiàn)了一個奇怪的問題。簡單說來，就是一個以無條件方式申請消息的任務竟然在沒有取到消息的情況下，以指示“等待超時”的代碼返回了。 　　在這里，首先解釋一下任務申請消息的兩種方式：無條件方式和超時方式。所謂五條件方式是指任務申請消息時，如果暫時沒有消息可取，則任務將一直等待消息，直至取到為止；而超時方式是指任務等待消息是有時間限制的，超過所設定的最大時間，即便沒有取到消息，函數(shù)也可以正常返回，只是返回值不是消息，而是“超時代碼”(此方式可以防止任務因取不到消息而被永久性掛起)。可見，如果任務以無條件方式申請消息，那么函數(shù)若能夠返回，則說明任務一定是取到消息了，而返回值又怎么可能是“等待超
時”呢?經(jīng)過仔細分析smallrts5l的源代碼，找到了問題產(chǎn)生的根源。 　　假定有任務idx以超時方式調用osqpend()函數(shù)申請消息。osqpend()函數(shù)首先會把idx放到此消息隊列的等待任務表中，然后再去判斷隊列中是否有消息。最佳情況是隊列中確實有消息，則osqpend()再把idx從此消息隊列的等待任務表中刪除，接著osqpend()返回，任務取到消息。 　　此刻，假定消息隊列中設有消息。那么，osqpend()就會調用osclearsigna1(osrunningtaskid())和os-sched()這兩個系統(tǒng)函數(shù)，迫使idx進入休眠態(tài)，同時調度器調度下一個最高優(yōu)先級的就緒任務來運行。假定任務idy被選中，且idy在運行中通過調用osqintpost()函數(shù)向此消息隊列發(fā)送了一則消息。則osintpost（）將把所有等待這個消息隊列的任務中優(yōu)先級最高的那個任務喚醒，并且把它從該消息隊列的等待任務表中刪除，假定它就是idx?！　‘斎蝿読dy進入休眠態(tài)后，操作系統(tǒng)才會調度idx來運行。于是idx從上次被強迫休眠的地方開始運行，即從osqpend（）函數(shù)中緊接著ossched（）的那條指令開始執(zhí)行。具體來說，osqpend（）將首先查看idx是否滿足超時條件（用來判斷任務是因為等待超時被喚醒的還是因為確實取到消息而被喚醒的），若超時時限尚未到達，osqpend（）再接著檢查消息隊列中是否已經(jīng)有了消息。根據(jù)上面的假定，可以知道任務idx確實是因為取到消息而被喚醒的。于是，osqpend（）把idx從此消息隊列的等待任務表中刪除，osqpend（）正常返回。這樣，任務idx取到消息，接著運行。 　　以上都沒有什么問題，但是，有一種情況被忽略了，而正是這種情況的出現(xiàn)導致了任務idx被長時間掛起，就算隊列中有消息存在，idx也無法被喚醒，只能等到其超時為止。 　　為討論方便，不妨仍按上述假定情況來分析。當任務idx被喚醒且idy進入休眠狀態(tài)后，系統(tǒng)必將調度下一個優(yōu)先級最高的就緒任務來運行。在前面，認為這個任務就是idx，然而此時，假定它是另一個比idx優(yōu)先級更高的任務idz(因為有可能是中斷把idz喚醒的，所以中斷退出時，操作系統(tǒng)強制idy進入休眠態(tài)，轉而調度idz運行）。非常巧合的是，idz在運行的過程中向同一個消息隊列也申請了消息。由于之前idy已經(jīng)向消息隊列發(fā)送過一條消息，則idz將正常取到此條消息。于是，消息隊列中的消息數(shù)減為o（buf[0]==0）。在任務idz進入休 眠后，任務idx被操作系統(tǒng)調入cpu運行。同樣，函數(shù)osqpend（）首先查看idx是否等待超時。如果沒有超時再檢查消息隊列中是否存在消息。注意到先前已經(jīng)假定消息被任務idz給取走了，所以檢查的結果當然是隊列中不存在消息。idx就只好再次進入休眠，函數(shù)ossched（）調度別的任務運行。 　　于是問題出現(xiàn)了。idx是因為暫時取不到消息而被掛起的，但此時這個消息隊列的等待任務表中已經(jīng)投有idx的蹤影了，它之前就已被那個發(fā)送消息的idy在osqintpost()函數(shù)中給刪除了。 　　結果，即使后面有任務再次向隊列中發(fā)送消息，idx也取不到了，因為消息發(fā)送函數(shù)osqintpost()已經(jīng)無法從消息隊列的等待任務表中找到idx了，它將被長時間掛起，直至超時。也就是說，任務idx明明可以取到消息的，卻取不到，最后只能以指示其等待超時的代碼返回。 　　這還是一種相對來說不太嚴重的錯誤，無非就是任務沒取到消息，以超時返回而已．如果任務idx以無條件方式申請消息，而又恰恰發(fā)生了上面的情況，會有什么樣的后果呢?由于osqpend()函數(shù)自身的特性，所謂五條件等待就是把超時時間設為0。結果任務idx被喚醒后，osqpend()必然會檢測到其已超時，然后又會檢測到隊列中沒有消息，所以就必然以“超時代碼”返回。結果就發(fā)生了文章開頭所說的一幕；一個必須在取到消息后才能返回的任務，居然在沒有取到消息的情況下以指示其等待超