Buddy算法的μC/OSII高可靠?jì)却婀芾矸桨?/h1>
本文引用地址:http://dyxdggzs.com/article/149483.htm內存管理是操作系統的中心任務(wù)之一,其主要任務(wù)是組織內存以容納內核和待執行程序,跟蹤當前內存的使用情況,在需要時(shí)為進(jìn)程分配內存,使用完畢后釋放并回收內存。目前嵌入式系統中常用的內存管理策略主要有兩種--靜態(tài)內存分配和動(dòng)態(tài)內存分配。
靜態(tài)內存分配: 編譯或鏈接時(shí)將所需內存分配好,程序運行起來(lái)后所分配的內存不釋放。對于實(shí)時(shí)性和可靠性要求極高的系統,不允許延遲或者分配失效,必須采用靜態(tài)內存分配的方式。
動(dòng)態(tài)內存分配: 根據程序執行過(guò)程中所需內存的大小而動(dòng)態(tài)分配內存的策略。此方案按需分配內存,避免了靜態(tài)分配中的內存浪費,靈活性比較強,給程序的實(shí)現帶來(lái)了很大方便。缺點(diǎn)是容易造成內存碎片,且容易造成程序響應不及時(shí)等問(wèn)題。
綜上所述,靜態(tài)內存分配和動(dòng)態(tài)內存分配各有優(yōu)點(diǎn),出于嵌入式系統可靠性、實(shí)時(shí)性及成本、功耗的考慮,如何在兩種方案中作出平衡的選擇是令嵌入式操作系統設計者頭疼的事。一般的嵌入式操作系統都是兩種方案的高效結合,μC/OSII也不例外。除此之外,嵌入式操作系統對內存的分配還有以下幾點(diǎn)要求:
① 可靠性。內存分配的請求必須得到滿(mǎn)足,如果分配失敗可能會(huì )帶來(lái)災難性的后果。比如,航天飛機的嵌入式操作系統若發(fā)生內存分配失效,損失是不可估量的。
② 快速性。嵌入式系統對實(shí)時(shí)性的保證,要求簡(jiǎn)單、快速地分配內存。
③ 高效性。嵌入式系統中內存是一種有限、昂貴的資源,內存分配要盡可能地減少浪費。
μC/OSII作為一種典型的嵌入式操作系統,其內存管理同樣要滿(mǎn)足以上3點(diǎn)要求,下面簡(jiǎn)單介紹μC/OSII的內存管理策略,并分析其不足之處。
2 μC/OSII動(dòng)態(tài)內存管理方案及不足
2.1 μC/OSII內存管理方案簡(jiǎn)介
μC/OSII內存管理模塊主要由一個(gè)數據結構體和5個(gè)函數組成:
◆ 內存控制塊數據結構OS_MEM;
◆ 內存分區創(chuàng )建函數OSMemCreate(void *addr, INT32U nblks, INT32U blksize, INT8U *err);
◆ 內存塊分配函數OSMemGet(OS_MEM *pmem , INT8U *err);
◆ 內存塊釋放函數OSMemPut(OS_MEM *pmem , void *pblk);
◆ 內存分區狀態(tài)查詢(xún)函數OSMemQuery(OS_MEM *pmem, OS_MEM_DATA *p_mem_data);
◆ 內存控制塊鏈表初始化函數OSMemInit(void)。
μC/OSII用一個(gè)內存控制塊(OS_MEM)來(lái)管理內存分區,主要通過(guò)以下4步來(lái)管理:
① 內存控制塊鏈表初始化函數OSMemInit()負責創(chuàng )建空內存控制塊結構的鏈表,鏈表長(cháng)度由內核OS_CFG.H文件中定義的OS_MAX_MEM_PART宏確定。
② 內存塊創(chuàng )建函數OSMemCreate()先從空內存控制塊結構鏈表上獲取一個(gè)空的內存控制根塊結構,根據用戶(hù)需要內存塊的大小來(lái)創(chuàng )建分區。一個(gè)分區中含有相同大小的內存塊,各內存塊也是通過(guò)鏈表鏈接起來(lái),而不同分區中的內存塊大小一般不同,如圖1所示的PartitiON # 1和Partition # 2中內存塊的大小是不同的。

圖1 μC/OSII通過(guò)內存控制塊管理內存
③ 內存塊分配函數OSMemGet()通過(guò)從內存控制塊鏈表中找到能夠滿(mǎn)足自己內存塊需要的內存控制塊,然后從這個(gè)內存控制塊指向的分區鏈表首部得到自己需要的內存塊。
④ 內存塊釋放函數OSMemPut()負責回收內存塊。當應用程序不再使用某一個(gè)內存塊時(shí),必須及時(shí)把它釋放,并放回到相應的內存分區中。
2.2 μC/OSII內存管理方案的不足之處
如前所述,μC/OSII的內存管理方案簡(jiǎn)短精煉,僅百余行代碼,5個(gè)函數就能勝任。然而考慮到第1節提到的嵌入式系統對內存管理策略的3個(gè)要求,μC/OSII的內存管理策略存在以下不足之處:
① 原μC/OSII內存管理方案可靠性不高。因為原方案中各內存分區之間是孤立的,沒(méi)有聯(lián)系。一個(gè)內存分區上的內存塊用完時(shí),不能利用其他分區上的內存塊,而只是簡(jiǎn)單地報錯,從而使系統可靠性大大降低。在內存塊大小及需求量不確定的場(chǎng)合,如果經(jīng)常發(fā)生內存申請得不到滿(mǎn)足的情況,是嵌入式系統所不能容忍的。
② 原μC/OSII內存管理方案中內存分配不夠靈活。舉個(gè)例子來(lái)說(shuō),一個(gè)應用程序需要大小為1 KB、512 B、256 B三種內存塊,原方案有兩種解決方案,一是創(chuàng )建一個(gè)內存塊大小為1 KB的內存分區,內存塊數目至少為3個(gè);二是創(chuàng )建3個(gè)內存分區,內存塊大小分別為1 KB、512 B、256 B。方案一創(chuàng )建了較少分區,性能有保證,但造成內存資源的浪費;方案二雖然沒(méi)有浪費內存,但卻調用3次OS_MemCreate()函數,效率較低。
內存管理是操作系統的中心任務(wù)之一,其主要任務(wù)是組織內存以容納內核和待執行程序,跟蹤當前內存的使用情況,在需要時(shí)為進(jìn)程分配內存,使用完畢后釋放并回收內存。目前嵌入式系統中常用的內存管理策略主要有兩種--靜態(tài)內存分配和動(dòng)態(tài)內存分配。
靜態(tài)內存分配: 編譯或鏈接時(shí)將所需內存分配好,程序運行起來(lái)后所分配的內存不釋放。對于實(shí)時(shí)性和可靠性要求極高的系統,不允許延遲或者分配失效,必須采用靜態(tài)內存分配的方式。
動(dòng)態(tài)內存分配: 根據程序執行過(guò)程中所需內存的大小而動(dòng)態(tài)分配內存的策略。此方案按需分配內存,避免了靜態(tài)分配中的內存浪費,靈活性比較強,給程序的實(shí)現帶來(lái)了很大方便。缺點(diǎn)是容易造成內存碎片,且容易造成程序響應不及時(shí)等問(wèn)題。
綜上所述,靜態(tài)內存分配和動(dòng)態(tài)內存分配各有優(yōu)點(diǎn),出于嵌入式系統可靠性、實(shí)時(shí)性及成本、功耗的考慮,如何在兩種方案中作出平衡的選擇是令嵌入式操作系統設計者頭疼的事。一般的嵌入式操作系統都是兩種方案的高效結合,μC/OSII也不例外。除此之外,嵌入式操作系統對內存的分配還有以下幾點(diǎn)要求:
① 可靠性。內存分配的請求必須得到滿(mǎn)足,如果分配失敗可能會(huì )帶來(lái)災難性的后果。比如,航天飛機的嵌入式操作系統若發(fā)生內存分配失效,損失是不可估量的。
② 快速性。嵌入式系統對實(shí)時(shí)性的保證,要求簡(jiǎn)單、快速地分配內存。
③ 高效性。嵌入式系統中內存是一種有限、昂貴的資源,內存分配要盡可能地減少浪費。
μC/OSII作為一種典型的嵌入式操作系統,其內存管理同樣要滿(mǎn)足以上3點(diǎn)要求,下面簡(jiǎn)單介紹μC/OSII的內存管理策略,并分析其不足之處。
2 μC/OSII動(dòng)態(tài)內存管理方案及不足
2.1 μC/OSII內存管理方案簡(jiǎn)介
μC/OSII內存管理模塊主要由一個(gè)數據結構體和5個(gè)函數組成:
◆ 內存控制塊數據結構OS_MEM;
◆ 內存分區創(chuàng )建函數OSMemCreate(void *addr, INT32U nblks, INT32U blksize, INT8U *err);
◆ 內存塊分配函數OSMemGet(OS_MEM *pmem , INT8U *err);
◆ 內存塊釋放函數OSMemPut(OS_MEM *pmem , void *pblk);
◆ 內存分區狀態(tài)查詢(xún)函數OSMemQuery(OS_MEM *pmem, OS_MEM_DATA *p_mem_data);
◆ 內存控制塊鏈表初始化函數OSMemInit(void)。
μC/OSII用一個(gè)內存控制塊(OS_MEM)來(lái)管理內存分區,主要通過(guò)以下4步來(lái)管理:
① 內存控制塊鏈表初始化函數OSMemInit()負責創(chuàng )建空內存控制塊結構的鏈表,鏈表長(cháng)度由內核OS_CFG.H文件中定義的OS_MAX_MEM_PART宏確定。
② 內存塊創(chuàng )建函數OSMemCreate()先從空內存控制塊結構鏈表上獲取一個(gè)空的內存控制根塊結構,根據用戶(hù)需要內存塊的大小來(lái)創(chuàng )建分區。一個(gè)分區中含有相同大小的內存塊,各內存塊也是通過(guò)鏈表鏈接起來(lái),而不同分區中的內存塊大小一般不同,如圖1所示的PartitiON # 1和Partition # 2中內存塊的大小是不同的。
圖1 μC/OSII通過(guò)內存控制塊管理內存
③ 內存塊分配函數OSMemGet()通過(guò)從內存控制塊鏈表中找到能夠滿(mǎn)足自己內存塊需要的內存控制塊,然后從這個(gè)內存控制塊指向的分區鏈表首部得到自己需要的內存塊。
④ 內存塊釋放函數OSMemPut()負責回收內存塊。當應用程序不再使用某一個(gè)內存塊時(shí),必須及時(shí)把它釋放,并放回到相應的內存分區中。
2.2 μC/OSII內存管理方案的不足之處
如前所述,μC/OSII的內存管理方案簡(jiǎn)短精煉,僅百余行代碼,5個(gè)函數就能勝任。然而考慮到第1節提到的嵌入式系統對內存管理策略的3個(gè)要求,μC/OSII的內存管理策略存在以下不足之處:
① 原μC/OSII內存管理方案可靠性不高。因為原方案中各內存分區之間是孤立的,沒(méi)有聯(lián)系。一個(gè)內存分區上的內存塊用完時(shí),不能利用其他分區上的內存塊,而只是簡(jiǎn)單地報錯,從而使系統可靠性大大降低。在內存塊大小及需求量不確定的場(chǎng)合,如果經(jīng)常發(fā)生內存申請得不到滿(mǎn)足的情況,是嵌入式系統所不能容忍的。
② 原μC/OSII內存管理方案中內存分配不夠靈活。舉個(gè)例子來(lái)說(shuō),一個(gè)應用程序需要大小為1 KB、512 B、256 B三種內存塊,原方案有兩種解決方案,一是創(chuàng )建一個(gè)內存塊大小為1 KB的內存分區,內存塊數目至少為3個(gè);二是創(chuàng )建3個(gè)內存分區,內存塊大小分別為1 KB、512 B、256 B。方案一創(chuàng )建了較少分區,性能有保證,但造成內存資源的浪費;方案二雖然沒(méi)有浪費內存,但卻調用3次OS_MemCreate()函數,效率較低。
評論