Real Time

Operating
System
Memory Aspect

Real Time Operating

System
Memory Aspect

Introduction
An RTOS is a class of operating systems that are
intended for real time-applications.
What is a real time application?
A real time application is an application that
guarantees both correctness of result and the
added constraint of meeting a deadline.

 An operating system (OS) is responsible for managing

the hardware resources of a computer and hosting
applications that run on the computer.
An RTOS also performs these tasks, but is specially
designed to run applications with very precise timing
and a high degree of reliability.
To be considered "real-time", an operating system
must have a known maximum time for each of the
critical operations that it performs (or at least be able
to guarantee that maximum most of the time) [2].

A real-time system is one whose correctness involves

both the logical correctness of outputs and their
timeliness [1]. It must satisfy response-time constraints
or risk severe consequences including failure [2].

Performance
One common misconception is that real-time
operating systems have better performance than
other general-purpose operating systems.
While real-time operating systems may provide
better performance in some cases due to less
multitasking between applications and services, this
is not a rule.
Actual application performance will depend on CPU
speed,
memory
architecture,
program
characteristics, and more.

Core Idea Behind RTOS

An operating system which follows the Real Time
criteria.
An RTOS will provide
deadlines will be met.

facilities

to

guarantee

An RTOS will provide scheduling algorithms in order

to enable deterministic behavior in the system.
An RTOS is valued more for predictability than
throughput

Requirement for RTOS Predictability

and Control
PredictabilityMost Critical with respect to time.
All service exectured within bounded and known
times.
Other services such as files, I/O Devices, fault
management should be predictable.

Visibility and ControlRTOS users must be able

to access and control hardware and system behavior.

At the same time, level of abstraction for handling
these should be convenient.

 OpennesRTOS should be an Open System.

Should define a flexible set of mechanisms without
forcing a particular policy on a user.
E.g. should allow choice of different policies for task
scheduling.

RTOS Functions and Services

Aspects of RTOS
Some of the research areas of RTOS are as follows:
Scheduling
Memory Management
Inter-task Communication
Interrupt Handlers
Interrupt Latency
Priority Based Scheduling
Exceptional Handling

Why Memory Management?

1. Dynamic memory allocation [13] should be supported, e.g., for
being able to react to dynamic changes in the system
environment.
2. Available memory resources should be used as efficiently as
possible. Wasting memory (e.g. by fragmentation, delayed
release of unused memory) should be avoided as much as
possible.
3. Virtual memory management (VMM) [14], [15], [16] should be
supported. VMM provides independent address spaces for
different tasks, is able to realize memory protection, and helps
to prevent fragmentation of the physical memory when
memory is allocated and de-allocated dynamically.

4. In order to fulfill real-time requirements, basic

operations like memory allocation, access and
release should be as fast as possible; the complexity
of these operations should be data independent and
limited by (small) upper bounds.

Memory Management
In a multiprogramming environment, it is essential for the
operating system to share available memory effectively
among processes.
Memory management policies are directly related to the
amount of memory required to execute those processes.
Memory management algorithms are designed to optimize
the number of runnable processes in primary memory while
avoiding conflicts that adversely affect system performance.
If a process is to remain in memory, the kernel must allocate
adequate units of memory.
If only part of a process needs to be in primary memory at

Memory Management in RTOS

The choice of an RTOS in the design process is
important for support of memory management
along with other factors.
An RTOS uses small memory size by including
only the necessary functionality for an application
while discarding the rest [5].

Memory Management in RTOS (Contd)

The choice of an RTOS in the design process is
important for support of memory management
along with other factors.
In a real-time environment, a process must be able
to guarantee continuous memory residence to
reduce latency and to prevent paging and
swapping [3].
Good response times may require small memory
footprints in resource-impoverished systems [2].

Memory Management Types

Memory Management performed by two Types.
Static Memory Management
Dynamic Memory Management

Static Memory Managementprovides tasks with

temporary data space.
Dynamic Memory ManagementEmployees
Memory Swapping.
Detail in Following slides.

Static Memory Management

Static memory management provides tasks with
temporary data space.
The systems free memory is divided into a pool of
fixed sized memory blocks, which can be
requested by tasks.
When a task finishes using a memory block it
must return it to the pool. Another way to provide
temporary space for tasks is via priorities [6].

 A pool of memory is dedicated to high priority

tasks and another to low priority tasks. The highpriority pool is sized to have the worst-case
memory demand of the system.
The low priority pool is given the remaining free
memory.
If the low priority tasks exhaust the low priority
memory pool, they must wait for memory to be
returned to the pool before further execution [6].

Dynamic Memory Management

Dynamic memory management employs memory
swapping, overlays, multiprogramming with a fixed
number of tasks (MFT), multiprogramming with a
variable number of tasks (MVT) and demand paging.
Overlays allow programs larger than the available
memory to be executed by partitioning the code and
swapping them from disk to memory.
In MFT, a fixed number of equalized code parts are in
memory at the same time. As needed, the parts are
overlaid from disk.

 MVT is similar to MFT except that the size of the

partition depends on the needs of the program in
MVT.
Demand paging systems have fixed-size pages
that reside in non-contiguous memory, unlike
those in MFT and MVT [7].
In many embedded systems, the kernel and
application programs execute in the same space
i.e., there is no memory protection.

Memory Locking
Locking memory is one of the most important issues for realtime applications [1].
Under most of the operating system, the memory residency of
a process is determined by its current state, the total available
physical memory, the number of active processes, and the
processes' demand for memory.
This residency is appropriate in a time-share environment.
This residency is often unacceptable for a real-time process.
In a real-time environment, a process must guarantee a
memory residence to reduce the process' memory access and
dispatch latency [2].

Memory Locking (Contd)

Real-time memory locking in most of the RTOSs is provided by a set of
library routines [3].
These routines allow a process running with super-user privileges to lock
specified portions of its virtual address space into physical memory.
Pages locked in this manner are exempt from paging until the pages are
unlocked or the process exits.
The operating system has a system-wide limit on the number of pages
that can be locked at any time.
This limit is a tunable parameter whose default value is calculated at boot
time.
The default value is based on the number of page frames minus another
percentage, currently set at ten percent.

Memory Sharing
Like Traditional OS, RTOSs also share memory.
RTOS memory sharing is given in Portable
Operating System Interface (POSIX) standard
of IEEE [4].

Real-time Aware Virtual Memory

Management Unit (RTMMU)
Combine dynamic and virtual memory management with
constant runtime bounds that do not depend on the memory
usage profile [12].
For this purpose RTMMU introduce an efficient data structure
named Virtual Regions Tree for constant-time management of
typical memory operations including de-allocations.
Unlike standard approaches, RTMMU approach does not rely on
delayed memory de-allocations to achieve its runtime
efficiency.
In contrast, every de-allocation is immediately executed,
leading to minimized memory footprints.

Two-Level Memory Management

Also known as System-on-a-Chip Dynamic Memory
Management Unit (SoCDMMU).
Level One is the operating system management of memory
allocated to a particular on-chip Processing Element.
In this way, processing elements (heterogeneous or onheterogeneous hardware or software) in a System-on-a-Chip
(SOC) can request and be granted portions of the global
memorry in a fast and deterministic time.
For an example of a four processing element SoC, the
dynamic memory allocation of the global on-chip memory
takes sixteen cycles per allocation/deallocation in the worst
case.

Efficient Dynamic Memory Allocator

[18]
This dynamic memory allocation scheme efficiently utilizes
the tiny memory space in operating systems.
It adaptively uses the techniques of sequential fits (bitmap
fits), segregated free lists, and the buddy systems to fulfill
the essential requirements for wireless sensor networks.
Generally, the sequential fits are good at minimizing
fragmentation ratio, and the segregated free lists perform
well in terms of execution time.
In addition, buddy systems can provide flexibility and
scalability to the target operating systems.

ST_MEMMGR [19]
The ST_MEMMGR follows the sequential allocation algorithm
with the first fit allocation policy.
The entire memory is maintained as a singly linked list of
allocated and free blocks.
During the allocation operation, the entire list is searched
sequentially in order to find the first free block large enough
to satisfy the allocation request.
It employs split and coalesce operations to best suite an
allocation request.
The allocation operation takes O(n) execution time since it
requires a sequential scan of the memory descriptors while

ST_COMPACT_MEMMGR [19]
The ST_COMPACT_MEMMGR utilizes memory
compaction in order to eliminate the problem of
external fragmentation leading to suboptimal usage
of memory.
However memory compaction involves reordering of
allocated blocks across the memory and thus a
mechanism is required to update the allocation
references, before any read/write operation is
attempted.
Contiki handles this problem, by introducing a level
of indirection.

ST_COMPACT_MEMMGR (Contd)
However in Contiki the programmer is required to get
an updated reference each time an attempt is made
to access the allocated block.
ST_COMPACT_MEMMGR employs a novel scheme to
automate the process of updating the allocation
references.
To automate the process of updating the allocation
references, the allocation reference pointers are kept
as global variables, and while allocating the
reference to the allocation pointer is passed as an
argument.

Commercial RTOSs and Memory

I select a prominent commercial RTOS and discuss its
Memory Management function.
I have selected

Windows CE
LynxOS
VxWorks
Jbed
pSOS

In General, Support for virtual memory management

exists in all of them but not necessarily paging. The users
are offered choices among multiple levels of memory
protection.

Windows CE
Windows CE [8] is a modular, portable real-time
embedded OS for small memory, mobile 32-bit
devices.
Windows CE slices CPU time among threads and
provides 256 priority levels. To optimize
performance, all threads are enabled to run in
kernel mode.
All kernel objects (such as processes, threads,
critical sections, mutexes, events and
semaphores) are dynamically allocated in virtual
memory.

LynxOS
LynxOS [9] is a POSIX compatible, multithreaded
OS designed for complex real-time applications
that require fast, deterministic response. It is
scalable from large switching systems down to
small-embedded products.
The OS depends upon hardware memory
management units for memory protection, but
does offer optional demand paging.

VxWorks
VxWorks [10] is a widely adopted RTOS in the
embedded industry with a visual development
environment. It is scalable with over 1800 APIs
and is available on popular CPU platforms.
It can be set up so that each task has a private
virtual memory upon request.

Jbed
Jbed [11] is a real-time operating system for
embedded systems. It supports applications and
device drivers written in Java.
It supports real-time memory allocation, exception
handling and automatic object destruction.

pSOS
The objects, in object-oriented pSOS, include
tasks, memory regions, message queues, and
semaphores.
A memory region is a physically contiguous block
of memory, created in response to a call from an
application. pSOS allocates memory regions to
tasks. As other objects, a memory region may be
local or global.

References
1. P.A. Laplante, Real-Time Systems Design and Analysis: An Engineers
Handbook, Second edition, IEEE Press, 1997.
2. Meghanathan, S. Baskiyar N. "A survey of contemporary real-time operating
systems."Informatica29, no. 2 (2005).
3. Oracle Real Time Programming and Administration, Chapter 12.
4. IEEE Information TechnologyPortable Operating System Interface (POSIX)
Part1:
5. C. Walls, RTOS for Microcontroller Applications, Electronic Engineering, vol.
68, no. 831, pp. 57-61, 1996.
6. S.R. Ball, Embedded Microprocessor Systems: Real World Design, Third
edition, Newnes, 2002.
7. P.A. Laplante, Real-Time Systems Design and Analysis: An Engineers
Handbook, Second edition, IEEE Press, 1997.

8. C. Muench, The Windows CE Technology Tutorial: Windows Powered Solutions for the
Developer, First edition, Addison Wesley, 2000.
9. LynxOS, http://www.lynuxworks.com, Accessed Nov 15, 2004.
10.VxWorks, http://www.windriver.com, Accessed Nov 10, 2004
11.System Application Program Interface, ANSI/IEEE Std 1003.1, 1996 Edition. Jbed RTOS,
12.Bohnert, Martin, and Christoph Scholl. "A dynamic virtual memory management under
real-time constraints." InEmbedded and Real-Time Computing Systems and
Applications (RTCSA), 2014 IEEE 20th International Conference on, pp. 1-10. IEEE, 2014.
13.P. R. Wilson, M. S. Johnstone, M. Neely, and D. Boles, Dynamic storage allocation: A
survey and critical review, in Memory Management, International Workshop IWMM 95,
ser. Lecture Notes in Computer Science, H. G. Baker, Ed., vol. 986, 1995, pp. 1116.
14.J. Fotheringham, Dynamic storage allocation in the Atlas computer, including an
automatic use of a backing store, Commun. ACM, vol. 4, no. 10, pp. 435436, 1961.
15.P. J. Denning, Virtual memory, ACM Comput. Surv., vol. 2, no. 3, pp. 153189, 1970.

16.B. Jacob and T. Mudge, Virtual memory: Issues of

implementation, Computer, vol. 31, no. 6, pp. 3343, 1998.
17.Shalan, Mohamed, and Vincent J. Mooney III. "Hardware
support for real-time embedded multiprocessor system-on-achip memory management." InProceedings of the tenth
international symposium on Hardware/software codesign, pp.
79-84. ACM, 2002.
18.Min, Hong, Sangho Yi, Yookun Cho, and Jiman Hong. "An
efficient dynamic memory allocator for sensor operating
systems." InProceedings of the 2007 ACM symposium on
Applied computing, pp. 1159-1164. ACM, 2007.
19.Das, Supratim, Amarjeet Singh, Surinder Pal Singh, and Amit
Kumar. "A Low Overhead Dynamic Memory Management