基于鏈?zhǔn)蕉询B的內(nèi)存管理方法與系統(tǒng)的制作方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及信息技術(shù)領(lǐng)域，關(guān)于計(jì)算機(jī)系統(tǒng)的動(dòng)態(tài)內(nèi)存管理，尤其是用于嵌入式 實(shí)時(shí)內(nèi)核中的內(nèi)存管理方法與系統(tǒng)，適于對(duì)由單片機(jī)作為主控，性能、資源相對(duì)有限的系 統(tǒng)，例如以實(shí)時(shí)內(nèi)核MadOS為基礎(chǔ)的嵌入式系統(tǒng)的內(nèi)存進(jìn)行高效管理。
【背景技術(shù)】
[0002] 在嵌入式系統(tǒng)領(lǐng)域，uCOS-II與FreeRTOS是兩個(gè)非常典型的實(shí)時(shí)內(nèi)核，其中內(nèi)存 管理方法也很具代表性。
[0003] 1、uCOS-II中的內(nèi)存管理
[0004] UC0S-II在嵌入式系統(tǒng)領(lǐng)域一直以其穩(wěn)定性著稱，它曾經(jīng)被用在美國(guó)的月球車之 中。其高穩(wěn)定性的一個(gè)重要原因在于，uCOS-II盡可能的避免使用動(dòng)態(tài)內(nèi)存，例如：uC0S-II 中的每一個(gè)線程堆棧都是一個(gè)預(yù)定義好的數(shù)組。換句話說，uCOS-II盡可能將內(nèi)存的分配 放在程序的編譯階段，而非運(yùn)行階段。
[0005] uCOS-II的內(nèi)存管理的核心思想是：先在源代碼里定義一塊數(shù)據(jù)，當(dāng)上層應(yīng)用需 要時(shí)，將這塊數(shù)據(jù)區(qū)域分配給上層應(yīng)用使用。具體而言，就是預(yù)先在代碼里定義一個(gè)全局 變量：unsigned char buffer。當(dāng)有上層應(yīng)用申請(qǐng)動(dòng)態(tài)內(nèi)存時(shí)，直接將buffer指針返回給 上層應(yīng)用。顯然，這里只定義了一塊內(nèi)存是肯定不夠用的，uCOS-II中將其定義為2維數(shù)組 buff er[X][y]，x是內(nèi)存塊的數(shù)量，y即每塊內(nèi)存的大小。假設(shè)y的值是64,那么當(dāng)上層應(yīng) 用實(shí)際需要一塊17字節(jié)的空間時(shí)，由于buffer是預(yù)先定義好的數(shù)組，不可能從內(nèi)部拆分， 所以，實(shí)際返回給應(yīng)用的是一塊64字節(jié)的內(nèi)存，如此一來，在應(yīng)用釋放這塊內(nèi)存之前，這塊 內(nèi)存中的64-17 = 47個(gè)字節(jié)就處于"無所事事"的狀態(tài)，造成內(nèi)存浪費(fèi)。
[0006] uCOS-II將上述方法做了改進(jìn)：定義多個(gè)y值不同的buffer，應(yīng)用根據(jù)自身的需 要，選擇最合適的尺寸進(jìn)行申請(qǐng)。例如：假設(shè)預(yù)先定義了 y值分別為32、64、128、256的4種 buffer，當(dāng)應(yīng)用需要60字節(jié)時(shí)，就向y值為64的buffer申請(qǐng)，當(dāng)應(yīng)用需要70字節(jié)時(shí)，就向 y值為128的buffer申請(qǐng)。這樣的做法一定程度上緩解了內(nèi)存浪費(fèi)，但是并沒有從根本上 解決問題。
[0007]uCOS-II內(nèi)存管理的核心在于一個(gè)數(shù)據(jù)結(jié)構(gòu)。uCOS-II把每一種y值對(duì)應(yīng)的2維 數(shù)組buffer稱作一個(gè)分區(qū)（Partition)，新建一個(gè)分區(qū)需要：
[0008] 1)定義一個(gè)全局2維數(shù)組buffer [x] [y]。
[0009] 2)取得一個(gè)由內(nèi)存管理模塊定義的0S_MEM結(jié)構(gòu)體，并對(duì)其初始化。將buffer下 的每一個(gè)內(nèi)存塊鏈接在一起，如圖1所示。
[0010] -個(gè)分區(qū)（pa)初建立時(shí)，形成了一條以pa.OSMemFreeList為頭部的單鏈表。
[0011] 當(dāng)需要向pa分區(qū)申請(qǐng)動(dòng)態(tài)內(nèi)存時(shí)，實(shí)際上是將鏈表中的一個(gè)元素刪除，并將這個(gè) 元素返回給上層應(yīng)用。
[0012] 當(dāng)需要向pa分區(qū)釋放動(dòng)態(tài)內(nèi)存時(shí)，實(shí)際是將欲釋放的內(nèi)存塊插入到鏈表頭部。
[0013] 可見，對(duì)于一種y值的buffer來說，使用者必須在源代碼里定義好x值，也就是 說，使用者必須對(duì)需要多少個(gè)內(nèi)存塊做出判斷。然而，在一個(gè)系統(tǒng)中，動(dòng)態(tài)內(nèi)存的使用時(shí)機(jī) 是不確定的，因此要得到X的值有兩種做法：
[0014] 1)大量實(shí)驗(yàn)，根據(jù)實(shí)驗(yàn)的結(jié)果確定x的值。但在實(shí)際項(xiàng)目中，這種方法是不可行 的，首先，需要考慮各種使用環(huán)境；再者，針對(duì)不同的項(xiàng)目，X的值需要重新進(jìn)行測(cè)試。這種 方法使得以往的工作成果變得不可重復(fù)利用，嚴(yán)重降低了工作效率。
[0015] 2)預(yù)設(shè)一個(gè)大值。在一個(gè)實(shí)際的嵌入式系統(tǒng)中，可能包含多個(gè)第三方模塊，有的 模塊有自己的內(nèi)存管理子模塊，這些模塊并不需要系統(tǒng)提供的內(nèi)存管理方法。那么當(dāng)x值 設(shè)得很大時(shí)，就會(huì)出現(xiàn)一種情況：系統(tǒng)自身的內(nèi)存管理模塊占用了大量的內(nèi)存，而利用率很 低，其他第三方模塊的內(nèi)存管理子模塊只占用很少的內(nèi)存，而不夠用。最終整個(gè)系統(tǒng)因?yàn)榈?三方模塊無法正常運(yùn)行而出現(xiàn)異常，甚至崩潰。
[0016] y值的確定也存在著與x值類似的問題。而且，有些情況下，應(yīng)用是沒法知道自己 在運(yùn)行到某一時(shí)刻是需要多少動(dòng)態(tài)內(nèi)存的，例如，一些自定的通信協(xié)議，會(huì)先傳輸一個(gè)固定 長(zhǎng)度的頭部，后面跟一個(gè)長(zhǎng)度可變的數(shù)據(jù)載荷，這個(gè)數(shù)據(jù)載荷需要用動(dòng)態(tài)內(nèi)存臨時(shí)存儲(chǔ)，那 么，應(yīng)用編程人員必須在代碼里，對(duì)申請(qǐng)哪個(gè)y值的動(dòng)態(tài)內(nèi)存進(jìn)行判斷，如果系統(tǒng)上存在多 個(gè)通信接口，而通信協(xié)議都具有上述的特征，還需要考慮如何將對(duì)y值的判斷方法抽象成 一般規(guī)則，以便能應(yīng)用到全部的接口上。
[0017]2、FreeRTOS中的內(nèi)存管理
[0018] FreeRTOS是實(shí)時(shí)內(nèi)核家族中的新成員，以開源的形式得到很多開發(fā)者的青睞。其 中的內(nèi)存管理方式與uCOS-II截然不同。
[0019] FreeRTOS內(nèi)存管理的核心思想是將整個(gè)內(nèi)存堆空間看作一個(gè)整體，遵循需要多 少，分配多少的原則進(jìn)行內(nèi)存管理。FreeRTOS中也有一個(gè)類似0S_MEM的數(shù)據(jù)結(jié)構(gòu)。
[0020] 在使用動(dòng)態(tài)內(nèi)存之前需要調(diào)用初始化API，對(duì)內(nèi)存堆進(jìn)行初始化，如圖2所示。
[0021] 1)初始化全局變量xStart、xEnd，這兩個(gè)變量都是xBlockLink類型的，其作用是 標(biāo)識(shí)空閑內(nèi)存鏈表的頭與尾。
[0022] 2)在內(nèi)存堆的首地址處插入一個(gè)xBlockLink結(jié)構(gòu)體，使之與xStart、xEnd -起 組成最初的空閑內(nèi)存鏈表：
[0023] 經(jīng)過初始化后的全局變量xStart、xEnd及內(nèi)存堆的狀態(tài)如圖3所示。
[0024] 當(dāng)申請(qǐng)動(dòng)態(tài)內(nèi)存時(shí)，掃描以xStart為頭，xEnd為尾的空閑內(nèi)存塊鏈表list，找出 一塊xBlockSize大于需求尺寸wantSize的內(nèi)存塊，然后：
[0025] 1)將該塊空閑內(nèi)存從list中刪除，并記錄表下該塊內(nèi)存的首地址ptr。
[0026] 2)在ptr+sizeof(xBlockLink)+wantSize的內(nèi)存處放置一個(gè)xBlockLink結(jié)構(gòu)體， 形成一個(gè)新的空閑塊：
[0027] 新尺寸=原尺寸-wantSize。
[0028] 3)將新形成的空閑塊插入到list中。
[0029] 4)將指針（ptr+sizeof(xBlockLink))返回給上層應(yīng)用。
[0030] 當(dāng)釋放動(dòng)態(tài)內(nèi)存時(shí)，將上層傳入的指針減去sizeof(xBlockLink)就得到該塊內(nèi) 存的xBlockLink結(jié)構(gòu)體指針，然后將該塊內(nèi)存插入到list鏈表中，即完成回收。
[0031] FreeRTOS的這種回收機(jī)制必須考慮一個(gè)重要的問題：內(nèi)存塊回收之后，如果存在 幾個(gè)連續(xù)的內(nèi)存塊，如何將他們合并？實(shí)際上，F(xiàn)reeRTOS并沒有考慮內(nèi)存合并的問題，那 么，隨著系統(tǒng)運(yùn)行時(shí)間的推移，將會(huì)產(chǎn)生大量的內(nèi)存碎片，最終，當(dāng)需要某一大尺寸的內(nèi)存 塊時(shí)，空閑內(nèi)存的總量是足夠的，但都是非常小的碎片，導(dǎo)致內(nèi)存分配失敗，進(jìn)而引起系統(tǒng) 功能混亂、甚至崩潰。
[0032] FreeRTOS在管理內(nèi)存時(shí)，會(huì)將list中的內(nèi)存塊按由小到大的順序排列，以便再分 配時(shí)，盡可能分配一塊小內(nèi)存給應(yīng)用，這樣就提升了內(nèi)存使用效率。但是，由于不對(duì)內(nèi)存塊 進(jìn)行合并，這樣的思路會(huì)導(dǎo)致一個(gè)問題，由于小內(nèi)存不斷細(xì)化，空閑鏈表list的前面會(huì)存 在大量的小塊，而這些小塊隨著自己越來越小，被利用的概率會(huì)越來越低，那么，當(dāng)查找一 塊較大的空閑內(nèi)存時(shí)，將會(huì)有大量的CPU時(shí)間浪費(fèi)在掃描那些細(xì)化的小塊上。
[0033] 另外，釋放內(nèi)存時(shí)uCOS-II與FreeRTOS都沒有考慮傳入一個(gè)錯(cuò)誤指針，即并非指 向有效動(dòng)態(tài)內(nèi)存塊的指針時(shí)應(yīng)該如何處理，如果不做處理，而對(duì)該無效內(nèi)存塊執(zhí)行釋放操 作，必然導(dǎo)致系統(tǒng)崩潰。

【發(fā)明內(nèi)容】

[0034] 本發(fā)明目的在于提供一種用于實(shí)時(shí)內(nèi)核的內(nèi)存管理方法，采用鏈?zhǔn)蕉询B，使得已 分配內(nèi)存塊向內(nèi)存堆的頭部"堆積"，從而減少內(nèi)存碎片的產(chǎn)生，同時(shí)提高實(shí)時(shí)內(nèi)核運(yùn)行時(shí) 動(dòng)態(tài)內(nèi)存的使用效率。
[0035] 本發(fā)明的上述目的通過獨(dú)立權(quán)利要求的技術(shù)特征實(shí)現(xiàn)，從屬權(quán)利要求以另選或有 利的方式發(fā)展獨(dú)立權(quán)利要求的技術(shù)特征。
[0036] 為達(dá)成上述目的，本發(fā)明提出一種用于實(shí)時(shí)內(nèi)核的內(nèi)存管理方法，包括：
[0037] 為內(nèi)存堆內(nèi)每一塊被分配的動(dòng)態(tài)內(nèi)存前面插入一個(gè)結(jié)構(gòu)體形成一個(gè)動(dòng)態(tài)內(nèi)存塊， 使得每個(gè)動(dòng)態(tài)內(nèi)存塊包括該結(jié)構(gòu)體和數(shù)據(jù)內(nèi)存區(qū)；每個(gè)動(dòng)態(tài)內(nèi)存塊的首地址都鏈接在一條 單鏈表上，其中所述的結(jié)構(gòu)體包括動(dòng)態(tài)