Chapter 7
Memory Management
Today

Exam I





Thursday thru Tuesday
79 Questions (50 match, 29 guess)
1 Sheet Handwritten Notes
Project 3 – Jurassic Park
Chapter 7 – Memory Management
BYU CS 345
Memory Management
2
Project 3 Assignment
Step 1: Delta Clock

Implement delta clock.


Design data structure to hold delta times/events. dc[4] 10 / sem1
Program an insert delta clock function
dc[3] 5 / sem2



insertDeltaClock(int time, Semaphore* sem);
High priority, mutex protected
Add 1/10 second function to decrement top
event and semSignal semaphore when 0



dc[5]
dc[2]
0 / sem3
dc[1]
2 / sem4
dc[0]
4
pollinterrupts or
High priority, mutex protected.
Thoroughly test the operation of your delta clock before proceeding.



os345p3.c
Print Delta Clock (dc): int P3_dc(int argc, char* argv[]);
Test Delta Clock (tdc): int P3_tdc(int argc, char* argv[]);


BYU CS 345
int dcMonitorTask(int argc, char* argv[]);
int timeTask(int argc, char* argv[]);
Memory Management
3
// ***********************************************************************
// test delta clock
int P3_tdc(int argc, char* argv[])
{
createTask( "DC Test“, dcMonitorTask, 10, argc, argv);
timeTaskID = createTask( "Time", timeTask, 10, argc, argv);
return 0;
} // end P3_tdc
extern Semaphore* tics1sec;
// *************************************************************************
// display time every tics1sec
int timeTask(int argc, char* argv[])
{
char svtime[64];
// ascii current time
while (1)
{
SEM_WAIT(tics1sec)
printf("\nTime = %s", myTime(svtime));
}
return 0;
} // end timeTask
BYU CS 345
// ***********************************************************************
// monitor the delta clock task
int dcMonitorTask(int argc, char* argv[])
{
int i, flg;
char buf[32];
int ttime[10] = { 90, 300, 50, 170, 340, 300, 50, 300, 40, 110 };
for (i=0; i<10; i++)
{
sprintf(buf, "event[%d]", i);
event[i] = createSemaphore(buf, BINARY, 0);
insertDeltaClock(ttime[i], event[i]);
}
printDeltaClock();
while (numDeltaClock > 0)
{
SEM_WAIT(dcChange)
flg = 0;
for (i=0; i<10; i++)
{
if (event[i]->state ==1)
{
printf("\n event[%d] signaled", i);
event[i]->state = 0;
flg = 1;
}
}
if (flg) printDeltaClock();
}
printf("\nNo more events in Delta Clock");
// kill dcMonitorTask
tcb[timeTaskID].state = S_EXIT;
return 0;
} // end dcMonitorTask
Memory Management
4
Project 3 Assignment
Step 2: Car Tasks

Implement simple car task.

Design car functionality and Jurassic Park interface.
worry about passengers or drivers yet.)
(Don’t
Semaphore* fillSeat[NUM_CARS];
Semaphore* seatFilled[NUM_CARS];
Semaphore* rideOver[NUM_CARS];
Action
For each car seat:
(3 times, then car takes
off)
Wait until ride over
Release driver
Release passengers
BYU CS 345
Car Task
Park Task
SEM_WAIT(fillSeat[carID]);
Get passenger
Save passenger rideDone[] semaphore
Get driver (if last passenger)
Save driver driverDone semaphore
SEM_SIGNAL(seatFilled[carID]);
SEM_WAIT(rideOver[carID]);
SEM_SIGNAL(driverDone);
SEM_SIGNAL(rideDone[i]);
Memory Management
 SEM_SIGNAL(fillSeat[carID]);
 SEM_WAIT(seatFilled[carID]);
 SEM_SIGNAL(rideOver[carID]);
5
Project 3 Assignment
Step 2: Car Tasks (example)
// For each car, do 3 times:
{
SEM_WAIT(fillSeat[carID]);
SEM_SIGNAL(getPassenger);
SEM_WAIT(seatTaken);
SWAP; // wait for available seat
SWAP; // signal for visitor
SWAP; // wait for visitor to reply
... save passenger "rideover" semaphore ...
SEM_SIGNAL(passengerSeated);
SWAP: // signal visitor in seat
// if last passenger, get driver
{
SEM_WAIT(needDriverMutex);
SWAP;
// wakeup attendant
SEM_SIGNAL(wakeupDriver);
SWAP;
... save driver "rideover" semaphore ...
// got driver (mutex)
SEM_SIGNAL(needDriverMutex); SWAP;
}
SEM_SIGNAL(seatFilled[carID]);
}
SEM_WAIT(rideOver[myID]);
SWAP; // signal next seat ready
SWAP; // wait for ride over
... release passengers and driver ...
BYU CS 345
Memory Management
6
Project 3 Assignment
Step 3: Visitor Tasks

Design visitor functionality and car task interface.
worry about tickets yet.)




(Don’t
Each task visitor should create its own timing semaphore, which is
used for timing functions (ie, arrival delay, standing in lines, time in gift
shop or museum.) The delta clock should be used to SEM_SIGNAL
these semaphores.
Park visitors should randomly arrive at the park over a 10 second
period. In addition, visitors should stand in lines for a random time
before requesting a ticket or entrance to the museum or gift shop (3
seconds maximum).
The “SWAP” directive should be inserted after every line of
code in your Jurassic Park simulation. Park critical code
must be protected by the parkMutex mutex.
The park simulation creates a “lostVisitor” task which sums
critical variables in the park to detect any lost visitors.
BYU CS 345
Memory Management
7
Project 3 Assignment
Step 3: Visitor Tasks



Use resource semaphores (counting) to control access
to the park, the number of tickets available, and the
number of people allowed in the gift shop and museum.
Use mutex semaphores (binary) to protect any critical
sections of code within your implementation, such as
when updating the delta clock, acquiring a driver to buy
a ticket or drive a tour car, accessing global data, or
sampling the state of a semaphore.
Use semaphores (binary) to synchronize and
communicate events between tasks, such as to awaken
a driver, signal data is valid, signal a mode change, etc.
BYU CS 345
Memory Management
8
Semaphores

Use resource semaphores (counting) to control access
to the park, the number of tickets available, and the
number of people allowed in the gift shop and museum.
// create MAX_TICKETS tickets using counting semaphore
tickets = createSemaphore("tickets", COUNTING, MAX_TICKETS); SWAP;
// buy a ticket (consume)
SEM_WAIT(tickets);
SWAP;
// resell ticket (produce)
SEM_SIGNAL(tickets);
SWAP;
CS 345
Lab 3 – Jurassic Park
Start with
MAX_TICKETS
9
Semaphores

Use mutex semaphores (binary) to protect any critical
sections of code, such as when updating the delta clock,
acquiring a driver to buy a ticket or drive a tour car,
accessing global data, or sampling the state of a
semaphore.
Only 1 visitor at a
// need ticket, (1 at a time)
time requesting
SEM_WAIT(getTicketMutex);
SWAP;
a ticket
{
// Signal needTicket, Signal wakeUpDriver,
Wait ticketReady,
}
// allow next visitor to purchase ticket
SEM_SIGNAL(getTicketMutex);
SWAP;
CS 345
Lab 3 – Jurassic Park
10
Semaphores

Use signal semaphores (binary) to synchronize and
communicate events between tasks, such as to awaken a
driver, signal data is valid, etc.
// signal need ticket (produce raised hand up)
SEM_SIGNAL(needTicket);
SWAP;
// wakeup driver (produce wakeup call, driver consumes)
SEM_SIGNAL(wakeupDriver);
SWAP;
// wait ticket available (consume, driver produced ticket)
SEM_WAIT(ticketReady);
SWAP;
// buy ticket (produce driver consumes notification)
SEM_SIGNAL(buyTicket);
SWAP;
// put hand down (consume, done)
SEM_WAIT(needTicket);
CS 345
SWAP;
Lab 3 – Jurassic Park
11
Shared Memory

Shared memory can be implemented using C global
memory when protected with mutex semaphores.
// protect shared memory access
SEM_WAIT(parkMutex);
;SWAP
// access inside park variables
myPark.numOutsidePark--;
myPark.numInPark++;
;SWAP
;SWAP
// release protect shared memory access
SEM_SIGNAL(parkMutex);
;SWAP
CS 345
Lab 3 – Jurassic Park
12
Passing Semaphores

Shared memory can be implemented using C global
memory when protected with mutex semaphores.
// signal resource ready
SEM_WAIT(resourceMutex); SWAP;
SEM_WAIT(needPassenger); SWAP:
gSemaphore = mySemaphore; SWAP;
SEM_SIGNAL(resourceReady); SWAP;
SEM_WAIT(resourceAcquired); SWAP;
SEM_SIGNAL(resourceMutex); SWAP;
// signal resource ready
SEM_SIGNAL(needPassenger); SWAP;
SEM_WAIT(resourceReady); SWAP:
gSemaphore = mySemaphore; SWAP;
SEM_SIGNAL(resourceAcquired); SWAP;
CS 345
Lab 3 – Jurassic Park
13
Jurassic Park struct
# Waiting to Enter Park
numOutsidePark
Tour Car Line
numInCarLine
# of Passengers
park.cars[ ].passengers
Ticket Line
numInTicketLine
Driver Status
typedef struct
park.drivers[ ]
{
# Tickets Available int numOutsidePark;
// # outside of park
numTicketsAvailable
int numInPark;
// # in park (P=#)
int numTicketsAvailable;
// # left to sell (T=#)
int numRidesTaken;
// # of tour rides taken (S=#)
# in Park
int
numExitedPark;
// # who have exited the park
numInPark
int numInTicketLine;
// # in ticket line
int numInMuseumLine;
// # in museum line
int
numInMuseum;
//
#
in museum
# Rides Taken
int numInCarLine;
// # in tour car line
numRidesTaken
int numInCars;
// # in tour cars
int numInGiftLine;
// # in gift shop line
# Exited Park
int numInGiftShop;
// # in gift shop
numExitedPark
int drivers[NUM_DRIVERS];
// driver state (-1=T, 0=z, 1=A, 2=B, etc.)
CAR cars[NUM_CARS];
// cars in park
} JPARK;
# in Gift Shop
numInGiftShop
CS 345
Gift Shop Line
numInGiftLine
# in Museum
numInMuseum
Lab 3 – Jurassic Park
Museum Line
numInMuseumLine
14
Project 3 Assignment
Step 4: Driver Tasks

Develop the driver task.




Design driver functionality and interface with visitor/car tasks.
Implement design and integrate with os345, visitor, and car
tasks. (Now is the time to worry about ticket sales and driver
duties.)
Add ticket sales and driver responsibilities.
When a driver is awakened, use the semTryLock function to
determine if a driver or a ticket seller is needed.
BYU CS 345
Memory Management
15
Project 3 Assignment
Driver Task
int driverTask(int argc, char* argv[])
{
char buf[32];
Semaphore* driverDone;
int myID = atoi(argv[1]) - 1;
SWAP;
// get unique drive id
printf(buf, "Starting driverTask%d", myID);
SWAP;
sprintf(buf, "driverDone%d", myID + 1);
SWAP;
driverDone = createSemaphore(buf, BINARY, 0);
SWAP;
// create notification event
while(1)
// such is my life!!
Should this
{
mySEM_WAIT(wakeupDriver);
SWAP;be mutexed?
// goto sleep
if (mySEM_TRYLOCK(needDriver))
// i’m awake
- driver needed?
{
// yes
driverDoneSemaphore = driverDone;
SWAP;
// pass notification semaphore
mySEM_SIGNAL(driverReady);
SWAP;
// driver is awake
mySEM_WAIT(carReady);
SWAP;
// wait for car ready to go
mySEM_WAIT(driverDone);
SWAP;
// drive ride
}
else if (mySEM_TRYLOCK(needTicket))
// someone need ticket?
{
// yes
mySEM_WAIT(tickets);
SWAP;
// wait for ticket (counting)
mySEM_SIGNAL(takeTicket);
SWAP;
// print a ticket (binary)
}
else break;
// don’t bother me!
}
return 0;
} // end driverTask
BYU CS 345
Memory Management
16
CS 345
Stalling’s Chapter
#
Project
1: Computer System Overview
2: Operating System Overview
4
P1: Shell
3: Process Description and Control
4: Threads
4
P2: Tasking
5: Concurrency: ME and Synchronization
6: Concurrency: Deadlock and Starvation
6
P3: Jurassic Park
7: Memory Management
8: Virtual memory
6
P4: Virtual Memory
9: Uniprocessor Scheduling
10: Multiprocessor and Real-Time Scheduling
6
P5: Scheduling
11: I/O Management and Disk Scheduling
12: File Management
8
P6: FAT
Student Presentations
6
BYU CS 345
Memory Management
17
Chapter 7 Learning Objectives
After studying this chapter, you should be able to:
 Discuss the principal requirements for memory
management.
 Understand the reason for memory partitioning and
explain the various techniques that are used.
 Understand and explain the concept of paging.
 Understand and explain the concept of segmentation.
 Assess the relative advantages of paging and
segmentation.
 Summarize key security issues related to memory
management.
 Describe the concepts of loading and linking.
BYU CS 345
Memory Management
18
Requirements
Memory Management Requirements

Relocation




Protection



Allow processes to share data/programs
Logical Organization


Prevent processes from interfering with the O.S. or other processes
Often integrated with relocation
Sharing


Users generally don’t know where they will be placed in main memory
May swap in at a different place (pointers???)
Generally handled by hardware
Support modules, shared subroutines
Physical Organization


Main memory verses secondary memory
Overlaying
BYU CS 345
Memory Management
19
Address Binding


A process must be tied to a
physical address at some point
(bound)
Binding can take place at 3 times

Compile time


Load time



Always loaded to same memory address

BYU CS 345
Compiler/Assembler
object
Linker
load module
relocatable code
stays in same spot once loaded
Execution time

source
may be moved during execution
special hardware needed
Memory Management
Loader
Executable
20
Memory Management Techniques

Fixed Partitioning



Dynamic Partitioning



Divide memory into partitions at boot time, partition sizes
may be equal or unequal but don’t change
Simple but has internal fragmentation
Create partitions as programs loaded
Avoids internal fragmentation, but must deal with external
fragmentation
Simple Paging


Divide memory into equal-size pages, load program into
available pages
No external fragmentation, small amount of internal
fragmentation
BYU CS 345
Memory Management
21
Memory Management Techniques

Simple Segmentation



Virtual-Memory Paging




Divide program into segments
No internal fragmentation, some external fragmentation
Paging, but not all pages need to be in memory at one time
Allows large virtual memory space
More multiprogramming, overhead
Virtual Memory Segmentation



Like simple segmentation, but not all segments need to be in
memory at one time
Easy to share modules
More multiprogramming, overhead
BYU CS 345
Memory Management
22
Fixed Partitioning



Main memory divided into
static partitions
Simple to implement
Inefficient use of memory



Small programs use entire
partition
Maximum active processes
fixed
Internal Fragmentation
BYU CS 345
Memory Management
Operating System
8M
8M
8M
8M
8M
23
Fixed Partitioning

Variable-sized partitions



assign smaller programs to smaller
partitions
lessens the problem, but still a
problem
Placement




2M
4M
6M
8M
Which partition do we use?


Operating System
8M
Want to use smallest possible partition
What if there are no large jobs waiting?
Can have a queue for each partition
size, or one queue for all partitions
8M
12 M
Used by IBM OS/MFT, obsolete
Smaller partition by using overlays
BYU CS 345
Memory Management
24
Placement Algorithm w/Partitions

Equal-size partitions


because all partitions are of equal size, it
does not matter which partition is used
Unequal-size partitions



can assign each process to the smallest
partition within which it will fit
queue for each partition
processes are assigned in such a way as to
minimize wasted memory within a partition
BYU CS 345
Memory Management
25
Process Queues
 When its time to load a process into main
memory the smallest available partition that will
hold the process is selected
Operating
System
New
Processes
BYU CS 345
Operating
System
New
Processes
Memory Management
26
Dynamic Partitioning



Partitions are of variable length and
number
Process is allocated exactly as much
memory as required
Eventually get holes in the memory.


external fragmentation
Must use compaction to shift processes so
they are contiguous and all free memory is
in one block
BYU CS 345
Memory Management
27
Allocation Strategies

First Fit


Best Fit


Search through all the spots, allocate the spot in
memory that most closely matches requirements.
Next Fit


Allocate the first spot in memory that is big enough to
satisfy the requirements.
Scan memory from the location of the last placement
and choose the next available block that is large
enough.
Worst Fit

The largest free block of memory is used for bringing
in a process.
BYU CS 345
Memory Management
28
Which Allocation Strategy?

The first-fit algorithm is not only the simplest but
usually the best and the fastest as well.


The next-fit algorithm will more frequently lead to
an allocation from a free block at the end of
memory.



May litter the front end with small free partitions that must
be searched over on subsequent first-fit passes.
Results in fragmenting the largest block of free memory.
Compaction may be required more frequently.
Best-fit is usually the worst performer.


Guarantees the fragment left behind is as small as possible.
Main memory quickly littered by blocks too small to satisfy
memory allocation requests.
BYU CS 345
Memory Management
29
Dynamic Partitioning Placement Algorithm
8K
8K
12K
12K
Allocate 18K
22K
Last
allocated
block (14K)
First Fit
18K
Next Fit
Best Fit
8K
6K
6K
14K
14K
36K
BYU CS 345
2K
8K
20K
Allocated block
Free block
6K
Before
After
Memory Management
30
Memory Fragmentation
Memory Fragmentation


As memory is allocated and deallocated
fragmentation occurs
External 

Enough space exists to launch a program,
but it is not contiguous
Internal 
Allocate more memory than asked for to
avoid having very small holes
BYU CS 345
Memory Management
31
Memory Fragmentation
Memory Fragmentation

Statistical analysis shows that given N
allocated blocks, another 0.5 N blocks will
be lost due to fragmentation.

On average, 1/3 of memory is unusable


(50-percent rule)
Solution – Compaction.


Move allocated memory blocks so they are
contiguous
Run compaction algorithm periodically


BYU CS 345
How often?
When to schedule?
Memory Management
32
Buddy System
Buddy System








Tries to allow a variety of block sizes while avoiding
excess fragmentation
Blocks generally are of size 2k, for a suitable range of k
Initially, all memory is one block
All sizes are rounded up to 2s
If a block of size 2s is available, allocate it
Else find a block of size 2s+1 and split it in half to create
two buddies
If two buddies are both free, combine them into a larger
block
Largely replaced by paging

Seen in parallel systems and Unix kernel memory allocation
BYU CS 345
Memory Management
33
Relocation
Addresses

Logical



Relative


reference to a memory location independent of
the current assignment of data to memory
translation must be made to the physical
address
address expressed as a location relative to
some known point
Physical

the absolute address or actual location
BYU CS 345
Memory Management
34
Relocation
Hardware Support for Relocation
Relative address
Process Control
Block
Base Register
Adder
Absolute
address
Program
Comparator
Interrupt to
operating system
Data / Stack
Bounds Register
Kernel Stack
Process image in
main memory
BYU CS 345
Memory Management
35
Relocation
Base/Bounds Relocation

Base Register



Bounds Register




Used to detect accesses beyond the end of
the allocated memory
May have length instead of end address
Provides protection to system
Easy to move programs in memory


Holds beginning physical address
Add to all program addresses
These values are set when the process is
loaded and when the process is swapped in
Largely replaced by paging
BYU CS 345
Memory Management
36
Paging
Paging



Partition memory into small equal-size chunks
and divide each process into the same size
chunks
The chunks of a process are called pages and
chunks of memory are called frames
Operating system maintains a page table for
each process


contains the frame location
for each page in the process
memory address consist of a
page number and offset
within the page
BYU CS 345
Memory Management
37
Paging
Paging (continued…)

Page size typically a power of 2 to simplify the
paging hardware

Example (16-bit address, 1K pages)




010101 011011010
Top 6 bits (010101)= page #
Bottom 10 bits (011011010) = offset within page
Common sizes: 512 bytes, 1K, 4K
A
0
1
2
3
BYU CS 345
B
-
C
7
8
9
10
D Free
4 13
5 14
6
11
12
Memory Management
38
Paging
Paging
Frame
Number
0
A.0
0
0
1
A.1
1
2
A.2
3
A.3
B.0
D.0
4
6
B.1
D.1
B.2
D.2
7
C.0
8
5
7
13
1
0
1
8
14
2
2
2
9
3
3
3
10
Process C
Process A
0
4
---
0
4
C.1
1
5
---
1
5
9
C.2
2
6
---
2
6
10
C.3
3
11
11
D.3
4
12
12
D.4
Process B
Free Frame List
Process D
13
14
BYU CS 345
Memory Management
39
Segmentation
Segmentation

Program views memory as a set of segments of
varying sizes






Supports user view of memory
Easy to handle growing data structures
Easy to share libraries, memory
Privileges can be applied to a segment
Programs may use multiple segments
Implemented with a segment table

Array of base-limit register pairs



BYU CS 345
Beginning address (segment base)
Size (segment limit)
Status bits (Present, Modified, Accessed, Permission,
Protection)
Memory Management
40
Segmentation
Segmentation/Paging

In Pentium systems




CPU generate logical addresses
Segmentation unit produces a linear address
Paging unit generates physical address in
memory
(Equivalent to an MMU)
logical
address
CPU
BYU CS 345
Segmentation
Unit
linear
address
Paging
Unit
Memory Management
physical
address
Physical
Memory
41
BYU CS 345
Memory Management
42
Exam I
27. Why would early versions of the UNIX operating
system be unsuitable for real-time applications?
a. Because a process executing in kernel mode acts
like a user functions.
b. Because a process executing in user mode may
not be preempted.
c. Because maximum latency to process an interrupt
could not be guaranteed.
d. Untrue. UNIX is well suited for real-time
applications.
30. During its lifetime, a process moves among a
number of states. The most important of these are
a. Executing and Blocked.
b. Idaho, Utah, Wyoming, and Nebraska.
c. New, Running, and Suspended.
d. Ready, Running, and Blocked.
62. What are the software contexts in which
concurrency becomes an issue?
e. Multiprogramming, modularity, system software
BYU CS 345
Memory Management
43