Buddy算法的μC/OSII高可靠內(nèi)存管理方案

1 內(nèi)存管理概述

內(nèi)存管理是操作系統(tǒng)的中心任務之一，其主要任務是組織內(nèi)存以容納內(nèi)核和待執(zhí)行程序，跟蹤當前內(nèi)存的使用情況，在需要時為進程分配內(nèi)存，使用完畢后釋放并回收內(nèi)存。目前嵌入式系統(tǒng)中常用的內(nèi)存管理策略主要有兩種--靜態(tài)內(nèi)存分配和動態(tài)內(nèi)存分配。

靜態(tài)內(nèi)存分配： 編譯或鏈接時將所需內(nèi)存分配好，程序運行起來后所分配的內(nèi)存不釋放。對于實時性和可靠性要求極高的系統(tǒng)，不允許延遲或者分配失效，必須采用靜態(tài)內(nèi)存分配的方式。

動態(tài)內(nèi)存分配： 根據(jù)程序執(zhí)行過程中所需內(nèi)存的大小而動態(tài)分配內(nèi)存的策略。此方案按需分配內(nèi)存，避免了靜態(tài)分配中的內(nèi)存浪費，靈活性比較強，給程序的實現(xiàn)帶來了很大方便。缺點是容易造成內(nèi)存碎片，且容易造成程序響應不及時等問題。

綜上所述，靜態(tài)內(nèi)存分配和動態(tài)內(nèi)存分配各有優(yōu)點，出于嵌入式系統(tǒng)可靠性、實時性及成本、功耗的考慮，如何在兩種方案中作出平衡的選擇是令嵌入式操作系統(tǒng)設計者頭疼的事。一般的嵌入式操作系統(tǒng)都是兩種方案的高效結合，μC/OSII也不例外。除此之外，嵌入式操作系統(tǒng)對內(nèi)存的分配還有以下幾點要求：

① 可靠性。內(nèi)存分配的請求必須得到滿足，如果分配失敗可能會帶來災難性的后果。比如，航天飛機的嵌入式操作系統(tǒng)若發(fā)生內(nèi)存分配失效，損失是不可估量的。

② 快速性。嵌入式系統(tǒng)對實時性的保證，要求簡單、快速地分配內(nèi)存。

③ 高效性。嵌入式系統(tǒng)中內(nèi)存是一種有限、昂貴的資源，內(nèi)存分配要盡可能地減少浪費。

μC/OSII作為一種典型的嵌入式操作系統(tǒng)，其內(nèi)存管理同樣要滿足以上3點要求，下面簡單介紹μC/OSII的內(nèi)存管理策略，并分析其不足之處。

2 μC/OSII動態(tài)內(nèi)存管理方案及不足

2.1 μC/OSII內(nèi)存管理方案簡介

μC/OSII內(nèi)存管理模塊主要由一個數(shù)據(jù)結構體和5個函數(shù)組成：

　　◆ 內(nèi)存控制塊數(shù)據(jù)結構OS_MEM；

　　◆ 內(nèi)存分區(qū)創(chuàng)建函數(shù)OSMemCreate（void *addr, INT32U nblks, INT32U blksize, INT8U *err）；

　　◆ 內(nèi)存塊分配函數(shù)OSMemGet（OS_MEM *pmem , INT8U *err）；

　　◆ 內(nèi)存塊釋放函數(shù)OSMemPut（OS_MEM *pmem , void *pblk）；

　　◆ 內(nèi)存分區(qū)狀態(tài)查詢函數(shù)OSMemQuery（OS_MEM *pmem, OS_MEM_DATA *p_mem_data）；

　　◆ 內(nèi)存控制塊鏈表初始化函數(shù)OSMemInit（void）。

μC/OSII用一個內(nèi)存控制塊（OS_MEM）來管理內(nèi)存分區(qū)，主要通過以下4步來管理：

① 內(nèi)存控制塊鏈表初始化函數(shù)OSMemInit（）負責創(chuàng)建空內(nèi)存控制塊結構的鏈表，鏈表長度由內(nèi)核OS_CFG.H文件中定義的OS_MAX_MEM_PART宏確定。

② 內(nèi)存塊創(chuàng)建函數(shù)OSMemCreate（）先從空內(nèi)存控制塊結構鏈表上獲取一個空的內(nèi)存控制根塊結構，根據(jù)用戶需要內(nèi)存塊的大小來創(chuàng)建分區(qū)。一個分區(qū)中含有相同大小的內(nèi)存塊，各內(nèi)存塊也是通過鏈表鏈接起來，而不同分區(qū)中的內(nèi)存塊大小一般不同，如圖1所示的PartitiON # 1和Partition # 2中內(nèi)存塊的大小是不同的。

圖1 μC/OSII通過內(nèi)存控制塊管理內(nèi)存

③ 內(nèi)存塊分配函數(shù)OSMemGet（）通過從內(nèi)存控制塊鏈表中找到能夠滿足自己內(nèi)存塊需要的內(nèi)存控制塊，然后從這個內(nèi)存控制塊指向的分區(qū)鏈表首部得到自己需要的內(nèi)存塊。

④ 內(nèi)存塊釋放函數(shù)OSMemPut（）負責回收內(nèi)存塊。當應用程序不再使用某一個內(nèi)存塊時，必須及時把它釋放，并放回到相應的內(nèi)存分區(qū)中。

2.2 μC/OSII內(nèi)存管理方案的不足之處

如前所述，μC/OSII的內(nèi)存管理方案簡短精煉，僅百余行代碼，5個函數(shù)就能勝任。然而考慮到第1節(jié)提到的嵌入式系統(tǒng)對內(nèi)存管理策略的3個要求，μC/OSII的內(nèi)存管理策略存在以下不足之處：

① 原μC/OSII內(nèi)存管理方案可靠性不高。因為原方案中各內(nèi)存分區(qū)之間是孤立的，沒有聯(lián)系。一個內(nèi)存分區(qū)上的內(nèi)存塊用完時，不能利用其他分區(qū)上的內(nèi)存塊，而只是簡單地報錯，從而使系統(tǒng)可靠性大大降低。在內(nèi)存塊大小及需求量不確定的場合，如果經(jīng)常發(fā)生內(nèi)存申請得不到滿足的情況，是嵌入式系統(tǒng)所不能容忍的。

② 原μC/OSII內(nèi)存管理方案中內(nèi)存分配不夠靈活。舉個例子來說，一個應用程序需要大小為1 KB、512 B、256 B三種內(nèi)存塊，原方案有兩種解決方案，一是創(chuàng)建一個內(nèi)存塊大小為1 KB的內(nèi)存分區(qū)，內(nèi)存塊數(shù)目至少為3個；二是創(chuàng)建3個內(nèi)存分區(qū)，內(nèi)存塊大小分別為1 KB、512 B、256 B。方案一創(chuàng)建了較少分區(qū)，性能有保證，但造成內(nèi)存資源的浪費；方案二雖然沒有浪費內(nèi)存，但卻調(diào)用3次OS_MemCreate（）函數(shù)，效率較低。