FreeRTOS

FreeRTOS merupakan sebuah mini kernel portabel yang merupakan core (jantung) dari sebuah sistem
operasi dan mengatur bagaimana user (pengguna) mengakses komputer dan menjalankan program pada computer.
Ukurannya hanya berkisar antara 4 kB – 9 kB. Karena ukurannya yang kecil inilah, FreeRTOS mampu memberikan
prosesor kemampuan processing yang lebih mudah dan waktu processing yang lebih cepat. FreeRTOS bersifat open
source dan royalty free, artinya source code kernel dapat dikembangkan dan didistribusikan oleh semua orang
secara bebas. FreeRTOS didesain untuk small embedded systems (sistem komputer berskala kecil). FreeRTOS
sendiri ditulis dengan menggunakan bahasa pemrograman C. FreeRTOS mendukung keluarga prosesor berikut ini.

 Altera  Luminary Micro / Texas  Silicon Labs (ex Cygnal)

 Atmel Instruments  ST
 Cortus  Microchip  TI
 Energy Micro  NEC  Xilinx
 Freescale  NXP  x86
 Fujitsu  Renesas

A. Struktur Dasar Direktori

FreeRTOS pada situs resminya menyediakan source code yang dapat didownload secara bebas, yang
terdiri dari source code untuk setiap jenis port prosesor-nya dan demo aplikasinya yang dapat digunakan pada
beberapa macam tipe prosesor yang telah disebutkan sebelumnya.
Struktur direktorinya sebenarnya sangatlah sederhana. Source code dari real time kernel-nya terdiri dari 3
file yang sudah umum digunakan dalam arsitektur pemrograman prosesor (4 file jika menggunakan konsep co-
routine). Ketiga file ini adalah tasks.c, queue.c, dan list.c. Setiap tipe arsitektur prosesor memerlukan kode
program kernel khusus. Kode program ini disimpan dalam direktori bernama Portable, yang berada di dalam
directory Source.
Dalam direktori Demo, terdapat file-file aplikasi demo, baik yang umum digunakan oleh semua tipe
prosesor (terdapat dalam direktori Common) maupun spesifik untuk tiap tipe arsitektur prosesor.

Untuk struktur direktori yang lebih lengkapnya dapat dilihat sebagai berikut.

FreeRTOS
¦
+-Demo Contains all directories associated with the demo
¦ ¦ application, one sub directory per port.
¦ ¦
¦ +-Common The demo application files that are used by all the
¦ ¦ ports.
¦ +-Dir x The demo application build files for port x
¦ +-Dir y The demo application build files for port y
¦
+-Source Contains all directories associated with the
¦ scheduler source code
¦
¦ 3 core scheduler files common to all ports (4 is
¦ using co routines)
¦
+-include Scheduler header files
¦
+-Portable Processor specific code.

B. Proses Scheduling
Sebagaimana yang telah diketahui sebelumnya bahwa FreeRTOS pada dasarnya merupakan sebuah
kernel atau jantung dari sistem operasi. Kernel mengatur bagaimana user (pengguna) menjalankan beberapa
program pada sistem operasi secara bersamaan. Setiap pengeksekusian program dalam sebuah sistem operasi
dapat disebut sebagai task. Atau program (dalam hal ini yang menggunakan kernel RTOS) dapat dipandang
juga sebagai kumpulan task yang independen yang berbeda tugasnya satu sama lain.
Untuk sistem operasi yang dapat melakukan pengeksekusian beberapa task sekaligus disebut bersifat
multitasking. Sifat multitasking ini sangat menguntungkan dalam manajemen task pada sebuah sistem operasi
karena dengan multitasking ini sekompleks apapun desain dari sebuah software/program maka akan menjadi
sederhana desainnya.
Sebuah prosesor biasa hanya bisa mengeksekusi sebuah task dalam satu periode waktu tertentu. Namun
dengan sifat multitasking, sebuah sistem operasi dapat secara cepat mengerjakan sebuah task bergantian
selama periode waktu yang sangat singkat tanpa harus menyelesaikan satu task dulu baru mengerjakan task
yang lain sehingga tampak seperti mengeksekusi beberapa task sekaligus. Hal ini dapat dijelaskan melalui
diagram pewaktuan berikut ini.

Diagram di sebelah atas menunjukkan sistem operasi yang seperti mengeksekusi beberapa task sekaligus
secara bersamaan. Sedangkan diagram di bawahnya menunjukkan pengeksekusian sebenarnya dari beberapa
task oleh sistem operasi.
Task memiliki berbagai macam state (keadaan) dalam proses pengeksekusiannya, yaitu:
- Running
Task dalam keadaan sedang dieksekusi.
- Ready
Task sudah siap/dapat dieksekusi, namun belum dijalankan karena ada task lain dengan prioritas yang
sama atau lebih besar sudah dijalankan terlebih dahulu.
- Blocked
Task tidak dapat dieksekusi dikarenakan task tersebut memanggil fungsi delay (vTaskDelay()) sehingga
task tersebut tidak dapat dieksekusi. State ini memiliki periode “timeout” tertentu (sesuai dengan fungsi
vTaskDelay()) sehingga akan dieksekusi kembali jika periode “timeout”-nya telah habis.
- Suspended
State ini hampir sama dengan state blocked. Bedanya state ini berlaku saat ada perintah (command) yang
masuk dan tidak memiliki periode “timeout” yang tetap
Untuk lebih jelasnya, dapat dilihat dari flowchart berikut.
 Untuk dapat menerapkan sifat multitasking ini, kernel memerlukan scheduler yang berfungsi untuk
menunda pengeksekusian sebuah task dan kemudian dilanjutkan pengeksekusiannya kembali mulai pada titik
periode waktu tertentu. Atau dengan kata lain, menjadwalkan (scheduling) pengeksekusian dari beberapa task
yang berbeda berdasarkan state dari tiap task yang akan dieksekusi. Scheduler berkerja berdasarkan scheduling
policy, yaitu sebuah algoritma proses yang digunakan oleh scheduler untuk menentukan task mana yang akan
dieksekusi pada periode waktu tertentu. State dari sebuah task juga tidak selalu tergantung dari scheduler,
seperti state blocked. Task bisa mengatur sendiri state-nya apakah ingin suspended atau blocked bergantung
dari perintah (command) yang dipanggil. Proses scheduling dapat dijelaskan melalui diagram pewaktuan
berikut ini.

Setiap task memiliki priority tersendiri dan biasanya diberikan nilai mulai dari 0 sampai
(configMAX_PRIORITIES - 1). Semakin tinggi nilai priority-nya semakin besar alokasi penggunaan RAM-
nya. Pada saat scheduler pertama kali dijalankan, task yang pertama kali dieksekusi adalah Idle Task. Idle Task
ini memiliki nilai priority 0 (priority terendah). Idle Task ini juga digunakan agar memori yang dialokasikan
untuk task sebelumnya hilang dan menjadi milik Idle Task yang alokasi penggunaan memorinya lebih kecil.
Idle Task juga dapat difungsikan untuk menset prosesor dalam mode power-saving (penghematan daya). Task
dapat dipanggil dengan fungsi API xTaskCreate() dan dihentikan/dihapus dengan fungsi API vTaskDelete().
Setiap task memiliki struktur yang sama, yaitu sebagai berikut.

void vATaskFunction( void *pvParameters )

{
for( ;; )
{
-- Task application code here. --
}
}
FreeRTOS sebenarnya merupakan kernel yang bersifat real time, artinya setiap ada perubahan proses
eksekusi task yang terjadi saat itu juga harus langsung direspon oleh kernel tanpa disimpan terlebih dahulu
state-nya (misalnya pada kernel yang bersifat non-real time). Sehingga aplikasi yang dijalankan pun juga
bersifat real time. Untuk itu, programmer sebelumnya sudah harus menentukan priority dari setiap task yang
akan dieksekusi. Scheduler disini sebenarnya hanya berfungsi untuk memastikan task dengan priority tertinggi
dijalankan terlebih dahulu pada periode waktu yang telah diberikan. Untuk task dengan priority yang sama,
dibutuhkan teknik pengalokasian waktu processing secara adil agar dapat dieksekusi “seolah-olah” secara
bersamaan. Di bawah ini, merupakan contoh diagram pewaktuan real time scheduling dari aplikasi/program
yang digunakan untuk menginputkan karakter yang diketikkan dari keyboard untuk ditampilkan pada
LCD.Program ini terdiri dari 3 task berbeda, yaitu Idle Task, vKeyHandlerTask, dan vControlTask.
vKeyHandlerTask dieksekusi saat sebuah tombol keyboard ditekan. Sedangkan vControlTask dieksekusi pada
periode waktu yang tepat untuk melakukan proses control cycle yang mengecek input dari tombol keyboard.
Dalam hal ini, vControlTask memiliki priority tertinggi dan lebih tinggi daripada vKeyHandlerTask.
Diagram di atas dapat dijelaskan sebagai berikut.
- Saat scheduler mulai berjalan, task pertama yang dieksekusi adalah Idle Task. \
- Pada t1, tombol keyboard sudah ditekan, vKeyHandlerTask dieksekusi karena mempunyai priority yang
lebih tinggi dari Idle Task.
- Pada t2, vKeyHandlerTask sudah selesai memproses tombolnya dan kemudian menampilkannya pada
LCD. vKeyHandlerTask tidak bisa melanjutkan tugasnya sampai ada tombol keyboard lagi yang ditekan
sehingga statenya menjadi suspended dan scheduler kembali menjalankan Idle Task.
- Pada t3, scheduler menjalankan vControlTask untuk melakukan proses control cycle berdasarkan timing
dari timer scheduler. vControlTask dalam hal ini memiliki priority tertinggi dibandingkan idle task
sehingga vControlTask dijalankan.
- Antara t3 dan t4, terjadi penekanan tombol keyboard. vKeyHandlerTask sudah bersiap untuk dieksekusi.
Namun karena vControlTask sedang melakukan proses control cycle dan masih mempunyai priority
tertinggi, maka vKeyHandlerTask belum bisa segera dijalankan.
- Pada t4, vControlTask sudah selesai menjalankan proses control cycle. vControlTask tidak dapat
dijalankan lagi sampai timer dari scheduler menyatakan vControlTask perlu dijalankan kembali. Hal ini
menyebabkan vControlTask berada dalam keadaan suspended sehingga vKeyHandlerTask mempunyai
prioritas tertinggi dan dapat dijalankan untuk memproses penekanan tombol keyboard yang dilakukan
sebelumnya.
- Pada t5, vKeyHandlerTask telah selesai menjalankan tugasnya. Karena tidak ada task yang dijalankan lagi,
maka scheduler menjalankan idle task.
- Antara t5 dan t6, timer scheduler menjalankan siklus control cycle. Namun tidak ada tombol keyboard
yang ditekan antara waktu t5 dan t6.
- Tombol selanjutnya ditekan saat t6, namun karena timer scheduler mengharuskan untuk menjalankan
siklus control cycle maka vControlTask mempunyai priority tertinggi sehingga sebelum vKeyHandlerTask
menyelesaikan prosesnya scheduler menset state vKeyHandlerTask menjadi suspended dan menjalankan
vControlTask..
- Pada t8, vControlTask kembali selesai menjalankan proses control cycle. vControlTask tidak dapat
dijalankan lagi sampai timer dari scheduler menyatakan vControlTask perlu dijalankan kembali. Hal ini
menyebabkan vControlTask berada dalam keadaan suspended sehingga vKeyHandlerTask mempunyai
prioritas tertinggi dan dapat dijalankan kembali untuk memproses penekanan tombol keyboard yang
dilakukan sebelumnya.
Selain task, FreeRTOS versi 4.0.0 ke atas juga telah mengijinkan aplikasi real time untuk dapat
menjalankan co-routine (disamping task) yang pengertiannya hampir sama dengan task. Perbedaannya adalah
co-routine dapat dijalankan secara optional, belum memiliki state suspended, dan hanya digunakan pada
prosesor yang berarsitektur sangat kecil yang memiliki keterbatasan penggunaan alokasi RAM karena co-
routine berbagi stack (alokasi waktu penggunaan memori). Seperti halnya task, co-routine memiliki priority
tersendiri dan biasanya diberikan nilai mulai dari 0 sampai (configMAX_CO_ROUTINE_PRIORITIES - 1).
Semakin tinggi nilai priority-nya semakin besar penggunaan alokasi RAM-nya. Co-routine selalu memiliki
priority yang lebih rendah dari task. Sehingga eksekusi co-routine selalu atau hanya dapat dilakukan setelah
Idle Task dimana saat Idle Task dipanggil, tidak ada task lain yang akan dieksekusi sehingga co-routine pun
dapat dieksekusi setelah Idle Task. Co-routine dapat dipanggil dengan fungsi API xCoRoutineCreate. Setiap
co-routine memiliki struktur yang sama, yaitu sebagai berikut.

void vACoRoutineFunction( xCoRoutineHandle xHandle, unsigned portBASE_TYPE

uxIndex )
{
crSTART( xHandle );

for( ;; )
{
-- Co-routine application code here. --
}

crEND();
}
Co-routine memiliki berbagai macam state (keadaan) dalam proses pengeksekusiannya, yaitu:
- Running
Co-routine dalam keadaan sedang dieksekusi.
- Ready
Co-routine sudah siap/dapat dieksekusi, namun belum dijalankan karena ada co-routine lain dengan
prioritas yang lebih tinggi sudah dijalankan terlebih dahulu atau bisa juga sebuah task sedang dieksekusi
atau dalam state running.
- Blocked
 Co-routine tidak dapat dieksekusi dikarenakan co-routine tersebut memanggil fungsi delay (crDelay())
sehingga co-routine tersebut diblok dan tidak dapat dieksekusi. Co-routine yang memiliki state blocked
tidak bisa digunakan dalam proses scheduling.
Untuk lebih jelasnya, dapat dilihat dari flowchart berikut.

Secara umum, karakteristik dari task dan co-routine dapat disimpulkan sebagai berikut.
 Task
- Lebih sederhana
- Tidak terbatas penggunaannya
- Prioritas paling utama
- Setiap task memiliki alokasi waktu (stack)-nya sendiri-sendiri sehingga membutuhkan alokasi
penggunaan RAM yang lebih besar
 Co-routine
- Alokasi waktu (stack)-nya lebih kecil karena tiap penggunaan stack dibagi oleh beberapa co-routine
sehingga alokasi penggunaan RAM menjadi lebih kecil.
- Prioritas setelah task, dan sesama co-routine memiliki prioritasnya sendiri-sendiri.
- Terbatasnya stack untuk co-routine membutuhkan perhatian yang lebih rumit/khusus.
- Terbatasnya fungsi API yang bisa dipanggil

C. Komunikasi Antar Task

Agar task-task yang dieksekusi dalam sebuah program dapat saling berkomunikasi, maka dibutuhkan :
1. Queues
Queues adalah bentuk utama dari komunikasi antar-task. Queues bisa digunakan untuk saling bertukar
pesan antar-task, antara interrupt (sebuah bentuk program yang dikirmkan untuk menunda suatu proses
yang sedang dilakukan oleh kernel dan menjalankan apa yang diperintahkan oleh program yang
mengirimkan interupsi tersebut) dan task. Queues bisa berisi “item” (yang pada dasarnya berisi sebuah
pesan program) berukuran tetap dimana ukuran setiap item dan jumlah item yang bisa ditampung telah
didefinisikan sebelumnya saat queue dibuat. Dalam banyak kasus (sesuai dengan namanya yang apabila
diartikan menjadi “antrian”), queues sering digunakan sebagai buffer antrian dengan prinsip FIFO (First In
First Out), artinya item yang masuk lebih dahulu juga akan keluar lebih dahulu.
Item diletakkan pada queue dengan cara dicopy dari sumbernya (bisa berupa task maupun interrupt).
Dengan metode ini, desain dari sebuah aplikasi/program akan menjadi lebih sederhana karena dua task
tidak dapat mengakses data/item tersebut secara bersamaan dan masalah mutual exclusion (jaminan hanya
satu proses yang mengakses sumber daya pada suatu interval waktu tertentu dan proses-proses yang lain
dilarang mengerjakan hal yang sama) sudah ditangani oleh queue.
Fungsi API Queue mengijinkan penetapan waktu pemblokiran sebuah block (block time) dari item
yang akan dikirimkan melalui queue. Apabila antrian queue telah penuh, maka task selanjutnya yang akan
mengirimkan item dikenai block time. Mekanisme penentuan block time ini berdasarkan kapan item yang
paling pertama masuk akan dikirim ke task lain. Sebuah task dengan priority yang lebih tinggi akan
mempunyai block time yang lebih kecil sehingga task tersebut dapat mengirimkan item-nya lebih dahulu
ke queue daripada task dengan priority yang lebih kecil.
Queue dapat diilustrasikan melalui gambar berikut.
 Item dengan antrian masuk nomor 3 ke queue diterima terlebih dahulu oleh task B daripada item dengan
antrian masuk nomor 4 dimana item nomor antrian masuk 1 dan 2 sebelumnya telah dikirimkan dan
diterima oleh task B.
2. Binary Semaphores
Binary semaphores digunakan untuk menangani masalah mutual exclusion dan berhubungan dengan
sinkronisasi. Karena binary semaphore lebih cocok/baik digunakan untuk sinkronisasi, maka
penjelasannya dibatasi pada poin ini.
Seperti halnya queue, semaphore juga memiliki parameter block time. Prinsip kerja pemblokirannya
kurang lebih sama dengan queue.
Kita dapat mengasumsikan binary semaphore sebagai sebagai queue yang hanya dapat berisi satu item
saja sehingga keadaan queue bisa berupa terisi atau kosong. Task dan interrupt tidak memperdulikan item
apa yang berada di dalam queue. Task dan interrupt hanya memperhatikan apakah queue kosong
atau terisi. Mekaniskme ini bisa digunakan untuk sinkronisasi antara task interrupt dengan task.
Mekanismenya secara sederhana dapat dijelaskan sebagai berikut. Suatu komponen sistem yang
membutuhkan service tertentu akan mengirimkan interrupt ke scheduler dimana service ini sendiri
merupakan task yang nantinya harus dijalankan pada scheduler. Interrupt ini kemudian akan
“mengirimkan” semaphore ke queue (sehingga kondisinya menjadi terisi) untuk kemudian “diambil” oleh
task sehingga task tersebut dijalankan oleh scheduler. Apabila queue tidak terisi semaphore, maka task
tersebut tidak akan pernah dijalankan. Interrupt selalu “mengirimkan” semaphore, sedangkan task selalu
“mengambil” semaphore. Tidak akan pernah terjadi task yang “memberikan” semaphore, sedangkan
interrupt yang “mengambil” semaphore.

3. Counting Semaphores
Counting semaphores memiliki pengertian yang hampir sama dengan binary semaphores. Interrupt
dan task tidak memperdulikan apa yang ada di dalam queue semaphore. Interrupt dan task hanya
mengetahui apakah queue semaphore terisi atau kosong. Perbedaannya dengan binary semaphores adalah
counting semaphores memiliki queue yang dapat berisi lebih dari satu item.
Counting semaphores biasanya digunakan untuk :
- Counting Events
Pada kasus ini, event handler akan memberikan sebuah semaphore setiap satu siklus periode waktu
tertentu (didapat dengan cara mengurangi/decrement nilai cacahannya). Nilai cacahan (count value)-
nya adalah merupakan selisih antara jumlah siklus event yang telah terjadi dengan jumlah event yang
telah diproses.
- Resource Management
Pada kasus ini, nilai cacahan (count value) mengindikasikan jumlah resources (sumber daya) yang
tersedia. Untuk mendapatkan salah satu sumber daya yang tersedia, setiap task harus mendapatkan
semaphore terlebih dahulu sehingga mengurangi nilai cacahan. Apabila nilai cacahan menjadi 0, maka
tidak ada resources (sumber daya) yang tersedia. Ketika task telah selesai dieksekusi, maka task akan
 “mengembalikan” nilai semaphore ke queue counting semaphore sehingga menambah nilai
cacahannya.
4. Mutexes
Pada dasarnya, mutexes (‘MUT’ual ‘EX’clusion) juga merupakan binary semaphores. Sesuai dengan
kepanjangannya, mutexes lebih banyak digunakan untuk menangani kondisi mutual exclusion, yaitu
jaminan hanya satu proses yang mengakses sumber daya pada suatu interval waktu tertentu dan proses-
proses yang lain dilarang mengerjakan hal yang sama.
Ketika digunakan untuk mutual axclusion, mutex bertindak sebagai “tanda” yang menjaga resources.
Sebuah task yang akan mengakses/menggunakan resources harus mendapatkan “tanda” tersebut terlebih
dahulu. Jika task telah dieksekusi, maka “tanda” tersebut akan dikembalikan sehingga memberikan
kesempatan kepada task lain untuk mengakses resources yang sama.
Seperti halnya binary semaphores, mutex juga mengijinkan parameter block time. Task yang memiliki
priority lebih tinggi untuk mengakses resources memiliki block time yang lebih kecil daripada task dengan
priority yang lebih rendah.

5. Recursive Mutexes
Recursive mutexes sebenarnya berprinsip sama dengan mutexes. Hanya saja recursive mutexes
bersifat pengulangan, artinya setiap task dapat mengambil semaphore pada mutex secara berulang-ulang
dan jika task telah berhasil mengambil mutex dalam hitungan tertentu misalnya 5 kali, maka mutex tidak
akan dapat digunakan oleh task lain sampai task yang mengambil 5 mutex secara berulang tadi
mengembalikannya ke mutex 5 kali juga.

D. Manajemen Memori
Sebelum menjelaskan manajemen memori yang diterapkan pada FreeRTOS, ada baiknya terlebih dahulu
kita mengetahui proses pengeksekusian task yang terjadi pada memori, dalam hal ini register prosesor, RAM
dan ROM.
Sebuah task yang dieksekusi pasti akan menggunakan alokasi memori pada komputer untuk menyimpan
data maupun instruksi yang akan diproses, baik itu pada register prosesor, RAM, maupun ROM. Kumpulan
task yang dieksekusi pada berbagai macam resources memori ini disebut dengan context.
Task pada dasarnya merupakan sebuah urutan kode program. Task tidak pernah tahu kapan eksekusinya
akan ditunda maupun dijalankan kembali oleh kernel. Berikut ini merupakan contoh dari sebuah task yang
eksekusinya ditunda segera sebelum sebuah instruksi penjumlahan dari dua nilai yang tersimpan pada dua buah
register prosesor dilakukan.
Ketika task tersebut ditunda eksekusinya, ternyata dijalankan pengeksekusian sebuah task lain yang mengubah
nilai dari register prosesor yang sama. Apabila task yang sebelumnya ditunda eksekusinya dieksekusi kembali,
maka hasil dari penjumlahan kedua register tadi memberikan hasil yang tidak valid karena task yang
sebelumnya tidak mengetahui bahwa nilai kedua register telah diubah oleh task lain.
Untuk mencegah terjadinya error ini, saat task dijalankan kembali task harus memiliki context
berdasarkan proses penundaan dari task sebelumnya. Kernel dari sistem operasi harus memastikan bahwa
context dari sebuah task harus disimpan segera setelah task tersebut ditunda pengeksekusiannya. Saat task
dieksekusi kembali, maka context dari sebuah task dikembalikan oleh kernel sistem operasi sehingga tidak
terjadi error. Proses ini dinamakan context switching.
Kembali ke konsep manajemen memori pada FreeRTOS. Kernel RTOS harus mengalokasikan RAM
setiap task, queue, maupun semaphore dibuat. Setiap embedded/real-time system bisa memiliki syarat-syarat
yang berbeda dalam penggunaan RAM-nya maupun sistem timing (pewaktuan)-nya. Alokasi penggunaan
RAM paling cocok diterapkan menggunakan konsep algoritma untuk sebuah aplikasi tertentu.
Untuk memenuhi syarat-syarat ini, fungsi API untuk pengalokasian memori ini telah disertakan dalam
direktori Portable. Setiap aplikasi dari tiap jenis embedded system memiliki implementasi tersendiri dalam
pengalokasian memorinya.
Tiga contoh skema pengalokasian RAM disertakan dalam source code FreeRTOS versi 2.5.0 ke atas.
Ketiga skema ini adalah file heap_1.c, heap_2.c and heap_3.c.
1. Skema 1 - heap_1.c
Skema ini merupakan skema yang paling sederhana di antara ketiga contoh skema yang disertakan. Skema
ini tidak mengijinkan memori yang telah teralokasi untuk dikosongkan. Skema ini cocok pada keadaan :
- Jika aplikasi program yang digunakan tidak pernah menghapus task atau queue yang sudah dibuat.
- Memerlukan jumlah waktu yang sama untuk mengembalikan sebuah block.
Skema ini cocok pada banyak real-time system yang berskala kecil yang mengharuskan setiap task dan
queue harus sudah dibuat sebelum kernel dijalankan.
2. Skema 2 - heap_2.c
Skema ini menggunakan algoritma yang paling cocok dan paling baik. Skema ini mengijinkan memori
yang telah teralokasi untuk dikosongkan. Karakteristik skema ini :
- Bisa digunakan pada pembuatan dan penghapusan berulang-ulang dari task dan queue.
 - Tidak boleh digunakan jika alokasi memori yang dikosongkan berukuran acak.
- Menimbulkan masalah memory fragmentation
- Tidak terlalu efisien
Skema ini cocok digunakan untuk kebanyakan real time system yang berskala kecil yang secara dinamis
selalu membuat task.
3. Skema 3 - heap_3.c
- Dapat mengimplementasi fungsi malloc() dan free() yang digunakan dalam proses pengalokasian
memori.
- Berpotensi meningkatkan ukuran source code kernel.
- Digunakan pada aplikasi PC dengan prosesor yang berarsitektur x86.