CSE204

Real Time Operating System (RTOS)

UNIT–II
Timer Services and
Real Time Memory Management
Realtime Memory Management
Courtesy: Phillips A.Laplante - “Real-Time Systems
design and analysis”, 3rd Edition, John Wiley &
Sons, 2004.
CPU Cache Hierarchy
 The CPU makes use of small, fast, Cost Speed
and very expensive registers.
CPU
 Main memory is cheaper and
greater capacity but takes much
longer to access. Cache –
 The CPU cache is used to exploit static RAM
locality – keeping copies of data
likely to be used again in faster Main Memory
access memory to reduce the – dynamic
average time taken to access the RAM
data.
 The cache sits in-between the fast Storage –
Hard drive,
static CPU registers, and the slow
FLASH
memory both in terms of cost and 3
speed.
CPU Cache - Why do we use cache

 90/10 Rule
◼ A typical processor spends 90% of its
execution time in 10% of the total program
code.
◼ This means we can store the critical 10% of
the code in a fast- accessible memory whereas
leave the rest 90% on a storage disk

© Copyright 2004 Dr. Phillip A. Laplante

4
Locality of reference
(or Principle of locality)
 In many cases, a process accesses the
same value, or related storage locations
much more frequently than others
◼ Temporal Locality - a process tends to reference
in the near future those locations that have
been referenced shortly before
▪ For example, a for (;;) loop
◼ Spatial Locality - a process tends to reference a
portion of the address space in the
neighbourhood of its last reference
▪ For example, a data array
© Copyright 2004 Dr. Phillip A. Laplante
5
Process Stack Management

 In a multitasking system, context for each

task needs to be saved and restored in
order to switch processes.
 This can be done by using one or more
run-time stacks or the task-control block
model.
 Run-time stacks work best for interrupt-
only systems, whereas the task-control
block model works best with full-featured
real-time operating systems.
© Copyright 2004 Dr. Phillip A. Laplante
6
Process stack management

Main stack evolution.

© Copyright 2004 Dr. Phillip A. Laplante

7
Managing the Stack
• In a run-time stack two simple routines –
save and restore – are necessary to handle
the run-time saving and restoring of context
• The save routine is called by an interrupt
handler to save the current context of the
machine into a stack area.
• Store routine to be called immediately
after interrupts have been disabled
• Restore routine should be called just
before interrupts are enabled and before
returning from the interrupt handler
© Copyright 2004 Dr. Phillip A. Laplante
8
Process stack management
void int_handler(void)
{
save(mainstack);
switch(interrupt)
{
case 1: int1();
break;
case 2: int2;
break;
case 3: int3;
break;
}
restore(mainstack);
}

void int1(void) /*interrupt handler 1 */

{
save(stack); /*save context on stack */
task1(); /*execute task 1*/
restore(stack); /*restore context from stack */
}

Pseudo code for interrupt handler and context switch.

© Copyright 2004 Dr. Phillip A. Laplante
9
The task control block model
 In task-control block model a (fixed or dynamic)
list of task-control blocks is kept.
 In the fixed case, n task-control blocks are
allocated at system generation time in the
dormant state.
 As tasks are created, the task-control block
enters the ready state.
 Prioritization or time slicing moves the task to the
executing state.
 If a task is to be deleted, its task-control block is
placed in the dormant state.
© Copyright 2004 Dr. Phillip A. Laplante
10
The task control block model
 In the case of a fixed number of task-control blocks, no
real-time memory management is necessary.
 In the dynamic case, task-control blocks are added to a
linked list or some other dynamic data structure as tasks
are created.
 Tasks are in the suspended state upon creation and enter
the ready state via an operating system call or event.
 The tasks enter the execute state owing to priority or time
slicing.
 When a task is deleted, its task-control block is removed
from the linked list, and its heap memory allocation is
returned to the available status.
 Real-time memory management consists of managing the
heap other data structure needed to supply the task-
control blocks.
© Copyright 2004 Dr. Phillip A. Laplante
11
Run-time ring buffer
 A run-time stack cannot be used in a round-robin
system because of the first-in/first-out (FIFO)
nature of the scheduling.
 In this case a ring buffer or circular queue can be
used to save context.
 The context is saved to the tail of the list and
restored from the head.
 The save and restore routines can be easily
modified to accomplish this operation.

© Copyright 2004 Dr. Phillip A. Laplante

12
Maximum stack size
 The maximum amount of space needed for the
run-time stack needs to be known a priori.
 In general stack size can be determined if
recursion is not used and heap data structures
are avoided.
 If maximum stack memory requirements are not
known, then a catastrophic memory allocation
can occur, and the system will fail to satisfy
event determinism.
 Ideally, provision for at least one more task than
anticipated should be allocated to the stack to
allow for spurious interrupts and time
overloading.

© Copyright 2004 Dr. Phillip A. Laplante

13
Multiple stack arrangements
 Single run-time stack is inadequate to manage several
processes
 A multiple-stack scheme uses a single run-time stack
and several application stacks
Advantages:
 Permits tasks to interrupt themselves, thus allowing
for handling transient overload conditions or for
detecting spurious interrupts
 Supports re-entrancy and recursion with individual
run-time stacks can be kept for each process
 In either case, a pointer to these stacks needs to be
saved in the context or task-control block associated
with that task
© Copyright 2004 Dr. Phillip A. Laplante
14
Multiple stack arrangements

Multiple stacks are needed to support runtime stacks for recursive languages.

© Copyright 2004 Dr. Phillip A. Laplante

15
Memory Management in TCB model
 When implementing TCB model of real-time multitasking,
the chief memory management issue is the maintenance of
the linked lists for the ready and suspended tasks

 When the currently executing task completes, is

preempted, or is suspended while waiting for a resource,
the next highest priority task in the ready list is removed
and is made the executing one.

 If the executing task needs to be added to the suspended

list, that is done

 If the executing task has completed, then its TCB is no

longer needed

© Copyright 2004 Dr. Phillip A. Laplante

16
Memory Management in TCB model
 Multiple lists may be maintained for each task in different
state

 Alternatively, a single list in which only the status variable

in the TCB is modified rather than moving the block

 This approach has the advantage of less list management

 Has a dis-advantage of slower traversal times, since the

entire list must be traversed during each context switch to
identify the next highest priority task that is ready to run

© Copyright 2004 Dr. Phillip A. Laplante

17
Memory Management in TCB model

© Copyright 2004 Dr. Phillip A. Laplante

18
Swapping
 A simple scheme that allows the operating system
to allocate memory to two processes
“simultaneously” is swapping.
 In this case, the operating system is always
memory resident, and one process can co-reside in
the memory space not required by the operating
system, called the user space.
 When a second process needs to run, the first
process is suspended and then swapped, along
with its context, to a secondary storage device,
usually a disk.
 The second process, along with its context, is then
loaded into the user space and initiated by the
dispatcher.
© Copyright 2004 Dr. Phillip A. Laplante
19
Swapping
 This scheme can be used along with
round-robin or preemptive priority
systems.
 The access time to the secondary store is
the principal contributor to the context
switch overhead and real-time response
delays.

© Copyright 2004 Dr. Phillip A. Laplante

20
Overlays
 A simple technique that allows a single program to
be larger than the allowable memory.
 Here the program is broken up into dependent
code and data sections called overlays, which can
fit into available memory.
 Special program code must be included that
permits new overlays to be swapped into memory
as needed (over the existing overlays), and care
must be exercised in the design of such systems.
 Some commercial real-time operating systems
support overlaying in conjunction with commonly
used programming languages and machines.
© Copyright 2004 Dr. Phillip A. Laplante
21
Overlays
 Overlaying has negative real-time implications
because the overlays must be swapped from
secondary storage devices.
 But overlaying can be used to extend the
available address space.
 In both swapping and overlaying a portion of
memory is never swapped to disk or overlaid.
 This memory contains the swap or overlays
manager (and in the case of overlaying any code
that is common to all overlays is called the root).

© Copyright 2004 Dr. Phillip A. Laplante

22
Block/page management:
Multiprogramming with Fixed Task (MFT)

 A more elegant scheme allows >1 process to be

memory-resident simultaneously by dividing the
user space into a number of fixed-size partitions.
 This scheme is useful in systems where the
number of tasks to be executed is fixed, as in
many embedded applications.
 Partition swapping to disk can occur when a task
is preempted.
 Tasks must reside in continuous partitions, and
the dynamic allocation and deallocation of
memory can cause problems.
© Copyright 2004 Dr. Phillip A. Laplante
23
 Block/page management

Fragmented memory is a serious problem in real-time systems. Fragmented

memory before (a) and after (b) compaction including unmovable blocks
(for example, representing the operating system root program).
© Copyright 2004 Dr. Phillip A. Laplante
24
Block/page management: MFT
 Internal fragmentation, occurs in fixed partition
schemes, e.g. when a process requires less
memory than available.
 Internal fragmentation can be reduced by creating
fixed partitions of several sizes and then allocating
the smallest partition greater than the required
amount.
 Both internal and external fragmentation hamper
efficient memory usage and degrade real-time
performance due to associated overhead.
 This dynamic memory allocation uses memory
inefficiently as a result of the overhead associated
with fitting a process to available memory and disk
swapping.
© Copyright 2004 Dr. Phillip A. Laplante
25
Block/page management: MFT
 In some commercial real-time executives,
memory is divided into regions in which each
region contains a collection of different-sized,
fixed-sized partitions.
 For example, one region of memory might consist
of 10 blocks of size 16Mb, while another regions
might contain 5 blocks of 32M, etc.
 The operating system tries to satisfy a memory
request so that the smallest available partitions
are used. This tends to reduce internal
fragmentation.
© Copyright 2004 Dr. Phillip A. Laplante
26
Block/page management:
Multiprogramming with Variable Task (MVT)
 In another scheme, memory is allocated in amounts that
are determined by the requirements of the process to be
loaded into memory.
 This technique is more appropriate when the number of
real-time tasks is unknown or varies.
 In addition, memory utilization is better for this technique
than for fixed block schemes because little or no internal
fragmentation can occur, as the memory is allocated in the
amount needed for each process.
 External fragmentation can still occur because of the
dynamic nature of memory allocation and deallocation, and
because memory must still be allocated to a process
contiguously.

© Copyright 2004 Dr. Phillip A. Laplante

27
Block/page management: MVT
 Compressing fragmented memory or
compaction can be used to mitigate
external fragmentation.
 Compaction is a CPU-intensive process
and not encouraged in hard real-time
systems.
 If compaction must be performed, it
should be done in the background, with
interrupts disabled.

© Copyright 2004 Dr. Phillip A. Laplante

28
Block/page management:
Demand Paging
 In demand page systems, program segments are permitted
to be loaded in noncontiguous memory as they are requested
in fixed-size pages.
 This scheme helps to eliminate external fragmentation.
 Program code that is not held in main memory is “swapped”
to secondary storage.
 When a memory reference is made to a location within a
page not loaded in main memory, a page fault exception is
raised.
 The interrupt handler for this exception checks for a free
page slot in memory. If none is found, a page frame must be
selected and swapped to disk (if altered)—a process called
page stealing.
 Paging is allows nonconsecutive references to pages via a
page table.
© Copyright 2004 Dr. Phillip A. Laplante
29
Block/page management:
Demand Paging
 Pointers are used to access the desired
page.
 These pointers may represent memory-
mapped locations to map to the desired
hard-wired memory bank; may be
implemented through associative
memory; or may be simple offsets into
memory, in which case the actual address
in main memory needs to be calculated
with each memory reference.
© Copyright 2004 Dr. Phillip A. Laplante
30
Block/page management
 Paging can lead to problems including
very high paging activity (thrashing),
internal fragmentation, and deadlock.
 It is unlikely that a system would use such
a scheme in an embedded real-time
system where the overhead would be too
great and the associated hardware
support is not usually available.

© Copyright 2004 Dr. Phillip A. Laplante

31
Replacement algorithms
 Several methods can be used to decide which
page should be swapped out of memory to disk,
 At the hardware level, the same techniques are
also applicable to cache block replacement.
 The most straightforward is first-in/first-out
(FIFO). Its overhead is only the recording of the
loading sequence of the pages.
 The best non-clairvoyant algorithm is the least
recently used (LRU) rule.
 The LRU rule simply states that the least recently
used page will be swapped out if a page fault
occurs.
© Copyright 2004 Dr. Phillip A. Laplante
32
Memory locking
 Another disadvantage of page swapping is
the lack of predictable execution times.
 It is often desirable to lock all or a certain
part of a process into memory to reduce
paging overhead and to make execution
times more predictable.
 Any process with one or more locked pages
is then prevented from being swapped out
to disk.

© Copyright 2004 Dr. Phillip A. Laplante

33
Memory locking
 Many commercial real-time kernels
provide memory locking.
 These kernels typically allow code or data
segments and the run-time stack segment
to be locked into main memory.
 Memory locking decreases execution times
for the locked modules and can be used to
guarantee execution times.
 But it makes fewer pages available for the
application, encouraging contention.
© Copyright 2004 Dr. Phillip A. Laplante
34
Working sets
 Working sets are based on the model of locality-
of-reference.
 If a list of recently executed program instructions
are observed on a logic analyzer it can be noted
that most of the instructions are localized to
within a small number of instructions.
 For example, in the absence of interrupts and
branching, the program is executed sequentially.
 Or, the body of a loop may be executed a large
number of times.
 When interrupts, procedure calls, or branching
occurs, the locality-of-reference is altered.
© Copyright 2004 Dr. Phillip A. Laplante
35
Working sets
 In working sets a set of local code windows is
maintained in the cache and upon accessing a
memory location not contained in one of the
working sets one of the windows in the working
set is replaced.
 Uses a replacement rule such as FIFO or LRU.
 Performance is based entirely on the size of the
working set window, the number of windows in
the working set, and the locality-of-reference of
the code being executed.

© Copyright 2004 Dr. Phillip A. Laplante

36
Real Time Garbage collection
 Garbage is memory that has been allocated but is no longer
being used by a task, that is, the task has abandoned it.
 Garbage can accumulate when processes terminate
abnormally without releasing memory resources.
 In C, if memory is allocated using the malloc procedure
and the pointer for that memory block is lost, than that
block cannot be used or properly freed.
 Garbage can also develop in object-oriented systems and
as a normal byproduct of languages such as C++.
 Real-time garbage collection is an important function that
must be performed either by the language’s run-time
support (e.g. in Java) or by the operating system, or
application programmer where garbage collection is not
part of the language.

© Copyright 2004 Dr. Phillip A. Laplante

37
Contiguous file systems
 Disk I/O is a problem that can be exacerbated by file
fragmentation.
 File fragmentation is analogous to memory fragmentation
and has the same associated problems.
 In addition, to the logical overhead incurred in finding the
next allocation unit in the file, the physical overhead of the
disk mechanism is a factor.
 For example, physical overhead involved in moving the
disk’s read/write head to the desired sector can be
significant.
 To reduce or eliminate this problem many commercial real-
time systems, such as real-time UNIX, force all allocated
sectors to follow one another on the disk.
 This technique is called contiguous file allocation.

© Copyright 2004 Dr. Phillip A. Laplante

38
Selecting commercial real-time
operating systems
 The following are desirable characteristics for
real-time systems:
◼ There are two timeliness
◼ design for survival under peak load
◼ predictability
◼ fault-tolerance
◼ maintainability
 ways to objectively determine the fitness of a
product for a given application.
◼ Rely on third party reports of success or failure.
◼ Compare alternatives based on manufacturer’s published
information from brochures, technical reports, and Web
sites.
© Copyright 2004 Dr. Phillip A. Laplante
39
Selecting commercial real-time
operating systems
 Consider thirteen selection criteria each
having a range where unity represents
the highest possible satisfaction of the
criterion and zero represents complete
non-satisfaction.
1. Minimum interrupt latency
2. Number of processes the operating system
can simultaneously support
3. System memory required to support the OS

© Copyright 2004 Dr. Phillip A. Laplante

40
Selecting commercial real-time
operating systems
4. Scheduling mechanisms supported (e.g. round-robin,
preemptive priority, both)
5. Communication mechanisms available
6. After-sale support provided by the company
7. Application software available
8. Number of different processors that the OS supports
9. Source code availability
10. Context switch time
11. Cost
12. Development platforms are available
13. Networks and protocols supported

© Copyright 2004 Dr. Phillip A. Laplante

41
Thank You