Slide 1-1
Computer Systems IIGordon College
Operating System Overview
Class Intro Operating System Class Two Directions: Practical
Linux+ Guide to Linux Certification and Lab Manual Lab
Experience
Slide 1-2
Theoretical Operating Systems (3rd Edition Gary Nutt) Lecture
and Projects
1
Why Study Operating Systems? Understand the model of operation
Easier to see how to use the system Enables you to write efficient
code
Slide 1-3
Learn to design an OS Even so, OS is pure overhead of real work
Application programs have the real value to person who buys the
computer
Perspectives of the Computerprint cut send save open() malloc()
fork()
Slide 1-4
read-disk
start-printer track-mouse
Application Software System Software Hardware
Application Software System Software Hardware
Application Software System Software Hardware (c) OS Programmer
View
(a) End User View
(b) Application Programmer View
2
System SoftwareIndependent of individual applications, but
common to all of them ExamplesC library functions A window system A
database management system Resource management functions The OS
Slide 1-5
Using the System SoftwareApplication Programmer
Slide 1-6
Software API System SoftwareCommand Line Interpreter Compiler
Loader Libraries Libraries Libraries Window System
Database Management System
OS
Hardware
3
Application Software, System Software, and the OS
Slide 1-7
Human-Computer Interface Application Software API System
Software (More Abstract Resources) OS Interface Trusted OS
(Abstract Resources) Software-Hardware Interface Hardware
Resources
The OS as Resource ManagerProcess: An executing program
Resource: Anything that is needed for a process to runMemory Space
on a disk The CPU
Slide 1-8
An OS creates resource abstractions An OS manages resource
sharing
4
Resource Abstractionload(block, length, device); seek(device,
236); out(device, 9) write(char *block, int len, int device, int
track, int sector) { ... load(block, length, device); seek(device,
236); out(device, 9); ... }
Slide 1-9
write(char *block, int len, int device,int addr);
fprintf(fileID, %d, datum);
Disk AbstractionsApplication Programmer OS Programmer
Slide 1-10
load(); seek(); out();
void write() { load(); seek() out() }
int fprintf() { ... write() }
(a) Direct Control
(b) write() abstraction
(c) fprintf() abstraction
5
Abstract ResourcesUser Interface Application Abstract Resources
(API) Middleware OS Resources (OS Interface) OS Hardware
Resources
Slide 1-11
Abstract MachinesIdea Program Idea Program Abstract Machines
Physical Machine
Slide 1-12
Result
Result
Idea
Program
Result
6
Resource Sharing Space- vs time-multiplexed sharing To control
sharing, must be able to isolate resources OS usually provides
mechanism to isolate, then selectively allows sharing How to
isolate resources How to be sure that sharing is acceptable
Slide 1-13
Concurrency
The OS as a Conductor
Slide 1-14
The OS coordinates the sharing and use of all the components in
the computer
7
MultiprogrammingAbstract Machine Pi Abstract Machine Pj Abstract
Machine Pk
Slide 1-15
OS Resource Sharing
Pi Memory Pk Memory
Time-multiplexed Physical Processor
Pj Memory
Space-multiplexed Physical Memory
Slide 1-16
Multiprogramming(2) Technique for sharing the CPU among runnable
processes Process may be blocked on I/O Process may be blocked
waiting for other resource, including the CPU
While one process is blocked, another might be able to run
Multiprogramming OS accomplishes CPU sharing automatically
scheduling Reduces time to run all processes
8
How Multiprogramming WorksProcess 1 Process 2 Process 3
Slide 1-17
Time-multiplexed CPUProcess 4
Space-multiplexed Memory
Speeding Up the Car WashVacuum Inside Wash
Slide 1-18
Dry
(a) The Sequential Car Wash
Vacuum Inside Wash (b) The Parallel Car Wash Dry
9
Multiprogramming PerformancePis Total Execution Time, ti0 ti
Slide 1-19
Time
(a) Pis Use of Machine ResourcesP1 P2 Pi PN
Time
(a) All Processes Use of Machine ResourcesUsing the processor
I/O operation
OS Strategies Batch processing Timesharing Personal computer
& workstations Process control & real-time Network
Distributed Small computers
Slide 1-20
10
Batch Processing
Slide 1-21
Job 19
Job 3
Input Spooler
Output Spooler
Input Spool
Output Spool
Batch Processing(2)
Slide 1-22
Uses multiprogramming Job (file of OS commands) prepared offline
Batch of jobs given to OS at one time OS processes jobs
one-after-the-other No human-computer interaction OS optimizes
resource utilization Batch processing (as an option) still used
today
11
A Shell Script Batch File
Slide 1-23
cc -g -c menu.c cc -g -o driver driver.c menu.o driver <
test_data > test_out lpr -PthePrinter test_out tar cvf
driver_test.tar menu.c driver.c test_data test_out uuencode
driver_test.tar driver_test.tar >driver_test.encode
Timesharing SystemsAbstract Machines ResultCommand
Slide 1-24
Physical Machine
ResultCommand
ResultCommand
12
Timesharing Systems(2)Computer Research Corp 67
Slide 1-25
Uses multiprogramming Support interactive computing model
(Illusion of multiple consoles) Different scheduling & memory
allocation strategies than batch Tends to propagate processes
Considerable attention to resource isolation (security &
protection) Tend to optimize response time
Personal Computers CPU sharing among one persons processes Power
of computing for personal tasks Graphics Multimedia
Slide 1-26
Trend toward very small OS OS focus on resource abstraction
Rapidly evolved to personal multitasking systems
13
Process Control & Real-Time Computer is dedicated to a
single purpose Classic embedded system Must respond to external
stimuli in fixed time Continuous media popularizing real-time
techniques An area of growing interest
Slide 1-27
Networks LAN (Local Area Network) evolution 3Mbps (1975) 10 Mbps
(1980) 100 Mbps (1990) 1 Gbps (2000) High speed communication means
new way to do computing Shared files Shared memory Shared
procedures/objects ???
Slide 1-28
14
Distributed OS Wave of the futureApp App App App Distributed OS
App App
Slide 1-29
Multiple Computers connected by a Network
Small Computers PDAs, STBs, embedded systems became commercially
significant Have an OS, but Not general purpose Limited hardware
resources Different kinds of devices Touch screen, no keyboard
Graffiti
Slide 1-30
Evolving & leading to new class of Oses
PalmOS, Pocket PC (WinCE), VxWorks,
15
Evolution of Modern OSTimesharingMemory Mgmt Scheduling Batch
Protection Memory Mgmt Protection Scheduling Files Devices
Slide 1-31
Network OS PC & WkstationSystem software Human-Computer
Interface Client-Server Model Protocols
Real-TimeScheduling
Small Computer Modern OSNetwork storage, Resource management
Examples of Modern OS UNIX variants (e.g. Linux) -- have evolved
since 1970 Windows NT/2K -- has evolved since 1989 (much more
modern than UNIX Win2K = WinNT, V5
Slide 1-32
Research OSes still evolving Small computer OSes still
evolving
16
The Microsoft OS FamilyWin32 API Win32 API Subset Win32 API
SubSet Windows CE (Pocket PC) Windows 95/98/Me
Slide 1-33
Windows NT/2000/XP
SummaryAn Operating System must be able to: provide
functionality to apps provide abstraction of hardware to users and
apps provide the sharing of resources to processes provide security
and protection be as transparent as possible be as light as
possible
Slide 1-34
17
Slide 2-1
Using the Operating System
The Airplane Pilots Abstract Machine
Slide 2-2
1
Basic AbstractionsIdea Program Idea Program Abstract Machine
Physical Machine Abstract Machine
Slide 2-3
Result
Result
Idea
Program
Abstract Machine
Abstract Machine Entities Process: A sequential program in
execution Resource: Any abstract resource that a process can
request, and which may can cause the process to be blocked if the
resource is unavailable. File: A special case of a resource. A
linearly-addressed sequence of bytes. A byte stream.
ResultSlide 2-4
2
Algorithms, Programs, and Processes IdeaExecution Engine
Slide 2-5
Algorithm
Status Stack
Files Files Files
Source Program
Binary Program
Data
Other Resources
Process
Classic Process
Slide 2-6
OS implements {abstract machine} one per task Multiprogramming
enables N programs to be space-muxed in executable memory, and
timemuxed across the physical machine processor. Result: Have an
environment in which there can be multiple programs in execution
concurrently*, each as a processes* Concurrently: Programs appear
to execute simultaneously
3
Process Abstraction
Slide 2-7
Data Process Program Stack Executable Memory
Operating SystemProcessor
Hardware
Processes Sharing a ProgramP1 P2 P3Files Files
Slide 2-8
P1Files Files
P2Files Files
Shared Program Text
P3
4
Multithreaded Accountant
Slide 2-9
Invoice First Accountant Purchase Orders Invoice
Invoice Second Accountant
Accountant & Clone Purchase Orders
(a) Separate Processes
(b) Double Threaded Process
Modern Process & Thread Divide classic process:
Slide 2-10
Process is an infrastructure in which execution takes place
address space + resources Thread is a program in execution within a
process context each thread has its own stackStack Data Process
ProgramThread Thread
Thread
Operating System
Stack
Stack
5
A Process with Multiple ThreadsThread (Execution Engine)Status
Stack Status Stack Status Stack Files Files Files Data Binary
Program Other Resources
Slide 2-11
Process
More on Processes Abstraction of processor resource Programmer
sees an abstract machine environment with spectrum of resources and
a set of resource addresses (most of the addresses are memory
addresses) User perspective is that its program is the only one in
execution OS perspective is that it runs one program with its
resources for a while, then switches to a different process
(context switching)
Slide 2-12
OS maintains A process descriptor data structure to implement
the process abstraction Identity, owner, things it owns/accesses,
etc. Tangible element of a process
Resource descriptors for each resource
6
Slide 2-13
Address Space Process must be able to reference every resource
in its abstract machine Assign each unit of resource an address
Most addresses are for memory locations Abstract device registers
Mechanisms to manipulate resources
Addresses used by one process are inaccessible to other
processes Say that each process has its own address space
Shared Address Space Classic processes sharing program shared
address space support Thread model simplifies the problem All
threads in a process implicitly use that processs address space ,
but no unrelated threads have access to the address space Now
trivial for threads to share a program and data
Slide 2-14
If you want sharing, encode your work as threads in a process If
you do not want sharing, place threads in separate processes
7
Process & Address Space
Slide 2-15
Code
Data Stack
Resources Resources Resources
Abstract Machine Environment
Address Space
Creating a Process Here is the classic model for creating
processes:
Slide 2-16
FORK(label)- Create another process in the same address space
beginning execution at instruction label QUIT()- Terminate the
process. JOIN(count)- Merge processes into one. Equivalent
Code:disableInterrupts(); count--; if(count > 0) QUIT();
enableInterrupts();
8
ExampleprocA() { while(TRUE) { ; update(x); ; retrieve(y); }
}
Slide 2-17
procB() { while(TRUE) { retrieve(x); ; update(y); ; } }
x Process A y Process B
Example (cont)L0: count = 2;
9
Slide 2-19
Example (cont)L0: count = 2; ; B2>
L3:
UNIX Processes
Slide 2-20
Status
Stack Segment Data Segment
Files Files Files
Text Segment
Other Resources
ProcessUNIX Kernel
10
UNIX Processes Each process has its own address space Subdivided
into text, data, & stack segment a.out file describes the
address space
Slide 2-21
OS kernel creates descriptor to manage process Process
identifier (PID): User handle for the process (descriptor) Try ps
and ps -aux (read man page)
A Process with Multiple ThreadsThread (Execution Engine)Status
Stack Status Stack Status Stack Files Files Files Data Binary
Program Other Resources
Slide 2-22
Process
11
Creating/Destroying Processes UNIX fork() creates a process
Creates a new address space Copies text, data, & stack into new
address space Provides child with access to open files
Slide 2-23
UNIX wait() allows a parent to wait for a child to terminate
UNIX execve() allows a child to run a new program
Creating a UNIX Process
Slide 2-24
int pidValue; ... pidValue = fork(); /* Creates a child process
*/ if(pidValue == 0) { /* pidValue is 0 for child, nonzero for
parent */ /* The child executes this code concurrently with parent
*/ childsPlay(); /* A procedure linked into a.out */ exit(0); } /*
The parent executes this code concurrently with child */
parentsWork(..); wait(); ...
12
Child Executes a Different Program
Slide 2-25
int pid; ... /* Set up the argv array for the child */ ... /*
Create the child */ if((pid = fork()) == 0) { /* The child executes
its own absolute program */ execve(childProgram.out, argv, 0); /*
Only return from an execve call if it fails */ printf(Error in the
exec terminating the child ); exit(0); } ... wait(); /* Parent
waits for child to terminate */ ...
Example: Parent#include #define NULL 0
Slide 2-26
int main (void) { if (fork() == 0){ /* This is the child process
*/ execve("child",NULL,NULL); exit(0); /* Should never get here,
terminate */ } /* Parent code here */ printf("Process[%d]: Parent
in execution ...\n", getpid()); sleep(2); if(wait(NULL) > 0) /*
Child terminating */ printf("Process[%d]: Parent detects
terminating child \n", getpid()); printf("Process[%d]: Parent
terminating ...\n", getpid()); }
13
Example: Child
Slide 2-27
int main (void) { /* The child process's new program This
program replaces the parent's program */ printf("Process[%d]: child
in execution ...\n", getpid()); sleep(1); printf("Process[%d]:
child terminating ...\n", getpid()); }
Threads -- The NT ModelThread (Execution Engine)Status Stack
Status Stack Status Stack Files Files Files Data Binary Program
Other Resources
Slide 2-28
Process
14
Windows NT Process
Slide 2-29
#include ... int main(int argv, char *argv[]) { ... STARTUPINFO
startInfo; PROCESS_INFORMATION processInfo; ...
strcpy(lpCommandLine, C:\\WINNT\\SYSTEM32\\NOTEPAD.EXE temp.txt);
ZeroMemory(&startInfo, sizeof(startInfo)); startInfo.cb =
sizeof(startInfo); if(!CreateProcess(NULL, lpCommandLine, NULL,
NULL, FALSE, HIGH_PRIORITY_CLASS | CREATE_NEW_CONSOLE, NULL, NULL,
&startInfo, &processInfo)) { fprintf(stderr, CreateProcess
failed on error %d\n, GetLastError()); ExitProcess(1); }; /* A new
child process is now executing the lpCommandLine program */ ...
CloseHandle(&processInfo.hThread);
CloseHandle(&processInfo.hProcess); t_handle = CreateProcess(,
lpCommandLine, ); }
NT Threads
Slide 2-30
#include ... int main(int argv, char *argv[]) { t_handle =
CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, // pointer
to thread security attributes DWORD dwStackSize, // initial thread
stack size, in bytes LPTHREAD_START_ROUTINE lpStartAddress, //
pointer to thread function LPVOID lpParameter, // argument for new
thread DWORD dwCreationFlags, // creation flags LPDWORD lpThreadId
// pointer to returned thread identifier ); /* A new child thread
is now executing the tChild function */ Sleep(100) /* Let another
thread execute */ } DWPRD WINAPI tChild(LPVOID me) { /* This
function is executed by the child thread */ ... SLEEP(100); /* Let
another thread execute */ ... }
15
_beginthreadex()Single copy of certain variables in a process
Need a copy per thread
Slide 2-31
unsigned long _beginthreadex( void *security, unsigned
stack_size, unsigned ( __stdcall *start_address )( void * ), void
*arglist, unsigned initflag, unsigned *thrdaddr );
Resources Anything that a process requests from an OS Available
allocated Not available process is blocked
Slide 2-32
Examples Files Primary memory address space (virtual memory)
Actual primary memory (physical memory) Devices (e.g., window,
mouse, kbd, serial port, ) Network port many others
16
Files Data must be read into (and out of) the machine I/O
devices Storage devices provide persistent copy Need an abstraction
to make I/O simple the file A file is a linearly-addressed sequence
of bytes From/to an input device Including a storage device
Slide 2-33
The File AbstractionData Process Program Stack File
Slide 2-34
Operating SystemProcessor Executable Memory File Descriptor
Hardware
Storage Device
17
UNIX Files UNIX and NT try to make every resource (except CPU
and RAM) look like a file Then can use a common interface:open
close read write lseek ioctl Specifies file name to be used Release
file descriptor Input a block of information Output a block of
information Position file for read/write Device-specific
operations
Slide 2-35
UNIX File Example#include #include int main() { int inFile,
outFile; char *inFileName = in_test; char *outFileName = out_test;
int len; char c; inFile = open(inFileName, O_RDONLY); outFile =
open(outFileName, O_WRONLY); /* Loop through the input file */
while ((len = read(inFile, &c, 1)) > 0) write(outFile,
&c, 1); /* Close files and quite */ close(inFile);
close(outFile); }
Slide 2-36
18
Windows File Manipulation Program
Slide 2-37
#include #include #define BUFFER_LEN ... // # of bytes to
read/write /* The producer process reads information from the file
name in_test then writes it to the file named out_test. */ int
main(int argc, char *argv[]) { // Local variables char
buffer[BUFFER_LEN+1]; // CreateFile parameters DWORD dwShareMode =
0; // share mode LPSECURITY_ATTRIBUTES lpFileSecurityAttributes =
NULL; // pointer to security attributes HANDLE hTemplateFile =
NULL; // handle to file with attributes to copy // ReadFile
parameters HANDLE sourceFile; // Source of pipeline DWORD
numberOfBytesRead; // number of bytes read LPOVERLAPPED
lpOverlapped = NULL; // Not used here
Windows File Manipulation Program(2)
Slide 2-38
// WriteFile parameters HANDLE sinkFile; // Source of pipeline
DWORD numberOfBytesWritten; // # bytes written // Open the source
file sourceFile = CreateFile ( "in_test", GENERIC_READ,
dwShareMode, lpFileSecurityAttributes, OPEN_ALWAYS,
FILE_ATTRIBUTE_READONLY, hTemplateFile ); if(sourceFile ==
INVALID_HANDLE_VALUE) { fprintf(stderr, "File open operation
failed\n"); ExitProcess(1); }
19
Windows File Manipulation Program(3)
Slide 2-39
// Open the sink file sinkFile = CreateFile ( "out_test",
GENERIC_WRITE, dwShareMode, lpSecurityAttributes, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, hTemplateFile ); if(sinkFile ==
INVALID_HANDLE_VALUE) { fprintf(stderr, "File open operation
failed\n"); ExitProcess(1); }
Windows File Manipulation Program(4)
Slide 2-40
// Main loop to copy the file while ( ReadFile( sourceFile,
buffer, BUFFER_LEN, &numberOfBytesRead, lpOverlapped )
&& numberOfBytesRead > 0 ) { WriteFile(sinkFile, buffer,
BUFFER_LEN, &numberOfBytesWritten, lpOverlapped); } //
Terminating. Close the sink and source files
CloseHandle(sourceFile); CloseHandle(sinkFile); ExitProcess(0);
}
20
Shell Command Line InterpreterInteractive UserApplication &
System Software
Slide 2-41
Shell ProgramOS System Call Interface OS
The Shell Strategy% grep first f3 read keyboardShell Process
Slide 2-42
fork a process Process to execute command
f3
read file
21
Bootstrapping Computer starts, begins executing a bootstrap
program -- initial process Loads OS from the disk (or other device)
Initial process runs OS, creates other processes
Slide 2-43
Slide 2-44
Serial Port A Serial Port B Serial Port C
login login login
Serial Port Z
login
getty /etc/passwd
22
Objects A recent trend is to replace processes by objects
Objects are autonomous Objects communicate with one another using
messages Popular computing paradigm Too early to say how important
it will be ...
Slide 2-45
23
Slide 3-1
Operating System Organization
Purpose of an OSProcesses Coordinate Use of the Abstractions The
Abstractions
Slide 3-2
Create the Abstractions
1
OS Requirements Provide resource abstractions Process
abstraction of CPU/memory use Address space Thread abstraction of
CPU within address space
Slide 3-3
Resource abstraction Anything a process can request that can
block the process if it is unavailable NT uses object abstraction
to reference resources
File abstraction of secondary storage use
OS Requirements Device Management Process, thread, and resource
management Memory Management File Management
Slide 3-4
2
Device ManagementDevice-Independent Part
Slide 3-5
Device-Dependent Part
Device-Dependent Part
Device-Dependent Part
Device
Device
Device
Virtual Device Driversused in virtualization environments
Slide 3-6
emulate a piece of hardware - illusion of accessing real
hardware How does it work? Attempts by the guest operating system
to access the hardware are routed to the virtual device driver in
the host operating system as function calls
3
Process, Thread, and Resource ManagementProcess, thread, and
resource manager Thread Abstraction Process Abstraction Other
Generic Resource Manager
Slide 3-7
Multiprogramming
Primary Memory
Abstract Resources
Processor
Memory ManagementIsolation & Sharing
Slide 3-8
Process Manager
Block Allocation
Virtual Memory
Primary Memory
Storage Devices
4
File ManagementAbstraction of storage devices Interacts with
device and memory managers Modern OS: file system can be
distributed across a network of machines
Slide 3-9
Slide 3-10
OS Design Constraints Performance Protection and security
Correctness Maintainability Commercial factors Standards and open
systems
5
Two software design issues
Slide 3-11
Performance - OS must be efficient efficient use of resources
(CPU time and memory space) Maximize the availability of resources
Exclusive use of resources - OS must provide resource isolationOS
Mechanisms to Handle Performance and Exclusive use of resources
Processor Modes - hardware mode bit is used to distinguish between
OS and user instructions Kernels - most critical part of OS placed
in kernel (trusted software module) Method of invoking system
service - calling a system function or sending a message to a
system process
Performance The OS is an overhead function should not use too
much of machines resources Minimum functionality is to implement
abstractions Additional function must be traded off against
performance DOS: one process UNIX: low level file system
Slide 3-12
6
Exclusive Access to a Resource Exclusive control of a resource -
must be guaranteed OS provides mechanism to isolate processes OS
must also provide ability for processes to share Security Policy -
the machine specific strategy for managing access to resources
Trusted software - carefully constructed and part of OS
(us)Kernel
Slide 3-13
Untrusted software - temporary and unknown (them)Apps, system
software, and OS extensions
Exclusive Access to a ResourceProcessor Process A Process B
Supervisor Program
Slide 3-14
As Protected Object
7
Protection & Security
Slide 3-15
Multiprogramming resource sharing Therefore, need
software-controlled resource isolation Security policy: Sharing
strategy chosen by computers owner Protection mechanism: Tool to
implement a family of security policies
Processor Modes Mode bit: Supervisor or User mode Supervisor
mode Can execute all machine instructions Can reference all memory
locations
Slide 3-16
User mode Can only execute a subset of instructions Can only
reference a subset of memory locations
8
Kernels
Slide 3-17
The part of the OS critical to correct operation (trusted
software) Executes in supervisor mode The trap instruction is used
to switch from user to supervisor mode, entering the OS
Supervisor and User Memory
Slide 3-18
User Process Supervisor Process
User Space
Supervisor Space
9
Procedure Call and Message Passing Operating Systemssend(, A, );
receive(, B, );
Slide 3-19
call();
trap
send/receive
return;
receive(A, ); send(, B, );
System Call Using the trap Instruction fork(); fork() { trap
N_SYS_FORK() }
Slide 3-20
Trap Table
Kernel
sys_fork()
sys_fork() { /* system function */ return; }
10
A Thread Performing a System CallUser Space Kernel Space
Slide 3-21
Thread fork();
sys_fork() { }
Correctness & Maintainability
Slide 3-22
Security depends on correct operation of software trusted vs
untrusted software Maintainability relates to ability of software
to be changed If either is sufficiently important, can limit the
function of the OS Guiding a manned spaceship Managing a nuclear
reactor
11
Basic Operating System OrganizationProcess, Thread &
Resource Manager File Manager
Slide 3-23
Memory Manager
Device Manager
Processor(s)
Main Memory
Devices
Basic Operating System OrganizationDilemma - modularize vs.
flater design Modularize Four separate functional units Easier to
maintain and update Flater performance important UNIX - four parts
combined into one
Slide 3-24
12
Basic Operating System OrganizationProcess, Thread &
Resource Manager File Manager
Slide 3-25
Memory Manager
Device Manager
Processor(s)
Main Memory
Devices
MicroKernelMicroKernel - only essential trusted code thread
scheduling hardware device management fundamental protection
mechanisms other basic functions remainder of the 4 - into user
code Must use system call to microkernel
Slide 3-26
13
Modern OS KernelsUnix - first to support multiprogramming and
networking Windows version - more widely used
Slide 3-27
The UNIX ArchitectureInteractive User Application Programs OS
System Call Interface Driver InterfaceTrap Table
Slide 3-28
Libraries
Commands
Device Driver Device Driver
Monolithic Kernel ModuleProcess Management Memory Management
File Management Device Mgmt Infrastructure
Device Driver
14
Windows NT OrganizationT
Slide 3-29
ProcessT T T
T
ProcessT T T
LibrariesUser Supervisor
Subsystem
Process Management Memory Management File Management Subsystem
Subsystem Device Mgmt Infrastructure
Process
T
NT Executive NT Kernel Hardware Abstraction LayerProcessor(s)
Main Memory
I/O Subsystem
Devices
NT Design GoalsExtensibility configured for workstation or
server OS uses the same source code in both extensible nucleus
software model like microkernel Portability Reliability and
Security
Slide 3-30
15
Windows NT OrganizationT
Slide 3-31
ProcessT T T
T
ProcessT T T
LibrariesUser Supervisor
Subsystem
Process Management Memory Management File Management Subsystem
Subsystem Device Mgmt Infrastructure
Process
T
NT Executive NT Kernel Hardware Abstraction LayerProcessor(s)
Main Memory
I/O Subsystem
Devices
Slide 3-32
DOS -- Resource Abstraction OnlyProgram Libraries Program
Program
OS Services ROM RoutinesProcessor(s) Main Memory Devices
16
Abstraction & SharingProcess Program State Process Program
State
Slide 3-33
Libraries
Process Program State
OS Services Abstraction Manage sharingProcessor(s) Main
Memory
ROM RoutinesDevices
Slide 3-34
Microkernel OrganizationProcess LibrariesUser Supervisor
Process Process
Server
Server Microkernel
Server
Device Drivers
Processor(s)
Main Memory
Devices
17
Monitoring the KernelTask Manager pview pstatUser Supervisor
T
Slide 3-35
ProcessT T T
T
ProcessT T T
Process
T
Libraries Subsystem Subsystem Subsystem
NT Executive NT Kernel Hardware Abstraction LayerProcessor(s)
Main Memory
I/O Subsystem
Devices
18
Slide 4-1
Computer Organization
Stored Program Computers and Electronic DevicesPattern
Slide 4-2
Jacquard Loom
Variable Program
Stored Program Device Fixed Electronic Device
1
Program SpecificationSourceint . . a = d = a, b, c, d; . b + c;
a - 100;
Slide 4-3
Assembly Language; Code for a = b + c load R3,b load R4,c add
R3,R4 store R3,a ; Code for d = a - 100 load R4,=100 subtract R3,R4
store R3,d
Machine LanguageAssembly Language; Code for a = b + c load R3,b
load R4,c add R3,R4 store R3,a ; Code for d = a - 100 load R4,=100
subtract R3,R4 store R3,d
Slide 4-4
Machine Language101110010011001 101110010100000 101001110011000
101110100011001 101110010100000 101001100011000 101110011011001
2
The von Neumann ArchitectureCentral Processing Unit
(CPU)Arithmetical Logical Unit (ALU) Control Unit (CU)
Slide 4-5
Address Bus Data BusPrimary Memory Unit (Executable Memory)
Device
The ALURight Operand Left Operand R1 R2 ... Rn load load add
store
Slide 4-6
R3,b R4,c R3,R4 R3,a
Functional UnitResult
Status Registers
To/from Primary Memory
3
Control Unitload load add store
Slide 4-7
R3,b R4,c R3,R4 R3,a
Fetch Unit
PCDecode Unit
3050 load R4, c
IRExecute Unit
3046 3050 3054 3058
101110010011001 101110010100000 101001110011000
101110100011001
Control Unit
Primary Memory
Control Unit Operation Fetch phase: Instruction retrieved from
memory Execute phase: ALU op, memory data reference, I/O, etc.PC =
; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) {
execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; // fetch
phase };
Slide 4-8
4
Primary Memory UnitMAR MDR Command1234 98765 read 1234 98765 0 1
2
Slide 4-9
Read Op: 1. Load MAR with address 2. Load Command with read 3.
Data will then appear in the MDR
n-1
The Device-Controller-Software RelationshipSoftware in the CPU
Application Program Abstract I/O Machine
Slide 4-10
Device manager Program to manage device controller Supervisor
mode software
Device Controller Device
5
Device Controller InterfaceBusy/done bits used to signal event
occurrences to software and software to device... busy done Error
code ...
Slide 4-11
busy done 0 0 idle 0 1 finished 1 0 working 1 1 (undefined)
Command
Status
Data 0 Data 1
LogicData n-1
Performing a Write Operationwhile(deviceNo.busy ||
deviceNo.done) ; deviceNo.data[0] = deviceNo.command = WRITE;
while(deviceNo.busy) ; deviceNo.done = TRUE;
Slide 4-12
Devices much slower than CPU CPU waits while device operates
Would like to multiplex CPU to a different process while I/O is in
process
6
CPU-I/O OverlapReady Processes Ready Processes Ready
Processes
Slide 4-13
CPU
CPU
CPU
Device
Device
Device
I/O Operation
Uses CPU
Slide 4-14
Determining When I/O is CompleteCPU
Interrupt Pending
Device
Device
Device
CPU incorporates an interrupt pending flag When device.busy
FALSE, interrupt pending flag is set Hardware tells OS that the
interrupt occurred Interrupt handler part of the OS makes process
ready to run
7
Control Unit with Interrupt (Hardware)PC = ; IR = memory[PC];
haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC +
sizeof(INSTRUCT); IR = memory[PC]; if(InterruptRequest) { memory[0]
= PC; PC = memory[1] };
Slide 4-15
memory[1] contains the address of the interrupt handler
Interrupt Handler (Software)
Slide 4-16
interruptHandler() { saveProcessorState(); for(i=0; ifire();
delete(thisEvent); }; }
33
Synchronization PrinciplesGordon College Stephen Brinton
The Problem with Concurrency Concurrent access to shared data
may result in data inconsistency Maintaining data consistency
requires mechanisms to ensure the orderly execution of cooperating
processes CONSUMER-PRODUCER problemin Producer count BUFFER out
Consumer
1
Producer-ConsumerPRODUCER while (true) {/* produce an item and
put in nextProduced
CONSUMER while (true) { while (count == 0) ; // do nothing
nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE;
count--;// consume the item in nextConsumered
while (count == BUFFER_SIZE) ; // do nothing buffer [in] =
nextProduced; in = (in + 1) % BUFFER_SIZE; count++; }
}
Race Condition count++ could be implemented as register1 = count
register1 = register1 + 1 count = register1 count-- could be
implemented as register2 = count register2 = register2 - 1 count =
register2 Consider this execution interleaving with count = 5
initially: S0: producer execute register1 = count {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6} S2:
consumer execute register2 = count {register2 = 5} S3: consumer
execute register2 = register2 - 1 {register2 = 4} S4: producer
execute count = register1 {count = 6 } S5: consumer execute count =
register2 {count = 4}
2
Solution to Critical Section1. Mutual Exclusion exclusive access
to the critical section of the cooperating group.do { Entry section
critical section Exit section remainder section } while (TRUE);
Solution to Critical Section (CS)1. Mutual Exclusion exclusive
access to the critical section of the cooperating group. 2.
Progress no process in CS then selection of process to enter CS
cannot be postponed indefinitely
3
Solution to Critical Section1. Mutual Exclusion exclusive access
to the critical section of the cooperating group. 2. Progress no
process in CS then selection of process to enter CS cannot be
postponed indefinitely 3. Bounded Waiting - There exists a bound
(or limit) on the number of times other processes can enter CS
after a process has made a request to enter and before it
enters.
Petersons Solution: Algorithmic Model Two process solution
Assume that the LOAD and STORE instructions are atomic; that is,
cannot be interrupted. The two processes share two variables: int
turn; Boolean flag[2] The variable turn indicates whose turn it is
to enter the critical section. The flag array: process is ready to
enter the critical section. If (flag[i] == true) implies that
process Pi is ready!
4
Petersons Solution: Process P1do { flag[i] = TRUE; turn = j;
while ( flag[j] && turn == j); CRITICAL SECTION flag[i] =
FALSE; REMAINDER SECTION } while (TRUE); Release Lock Acquire
Lock
Synchronization Hardware Many systems provide hardware support
for critical section code Uniprocessors could disable interrupts
Currently running code would execute without preemption Generally
too inefficient on multiprocessor systems (must tell all CPUs)
Operating systems using this not broadly scalable Modern machines
provide special atomic hardware instructions: Atomic =
non-interruptable Two types: test memory word and set value swap
contents of two memory words
5
TestAndndSet InstructionDefinition: boolean TestAndSet (boolean
*target) { boolean rv = *target; *target = TRUE; return rv: }
Solution Demo: TestAndndSet Instruction Shared boolean variable
lock., initialized to false. Solution: do { while ( TestAndSet
(&lock )) Acquire Lock ; /* do nothing // critical section
Release Lock
lock = FALSE; // remainder section
} while ( TRUE);
6
Solution Demo: TestAndndSet Instruction Shared boolean variable
lock., initialized to false. Solution: do { while ( TestAndSet
(&lock )) Acquire Lock ; /* do nothing // critical section
Release Lockboolean TestAndSet (boolean *target) { boolean rv =
*target; *target = TRUE; return rv: }
lock = FALSE; // remainder section
} while ( TRUE);
Swap InstructionDefinition: void Swap (boolean *a, boolean *b) {
boolean temp = *a; *a = *b; *b = temp: }
7
Solution Demo: Swap Instruction Shared Boolean variable lock
initialized to FALSE; Each process has a local Boolean variable
key. Solution: do { key = TRUE; while ( key == TRUE) Swap
(&lock, &key ); // critical section
lock = FALSE; // remainder section
} while ( TRUE);
Semaphore Does this require busy waiting? Semaphore S integer
variable Two standard operations modify S: wait() and signal()
Originally called P() and V() Less complicated Can only be accessed
via two indivisible (atomic) operationswait (S) { while S value--;
if (S->value < 0) { add this process to waiting queue
(S->list) block(); } }
Implementation of signal:signal (semaphore *S) { S->value++;
if (S->value list) wakeup(P); } }
10
Semaphore Implementation: no Busy waiting With each semaphore
there is an associated waiting
queue. Each entry in a waiting queue has two data items:
value (of type integer) pointer to next record in the list
Two operations:
block place the process invoking the operation on the
appropriate waiting queue.
wakeup remove one of processes in the waiting queue and place it
in the ready queue.
Semaphore Implementation Must be executed atomically: no
processes can execute
wait () and signal () on the same semaphore at the same time
Thus, implementation becomes the critical section
problem where the wait and signal code are placed in the
critical section. Could now have busy waiting in critical section
implementationBut
implementation code is short busy waiting if critical section
rarely occupied
Little
11
Deadlock and Starvation Deadlock two or more processes are
waiting indenitely for an event that can be caused by only one of
the waiting processes Let S and Q be two semaphores initialized to
1
P0 wait (S); wait (Q); . . signal (S); signal (Q); . .
P1 wait (Q); wait (S);
signal (Q); signal (S);
Starvation indenite blocking. A process may never be removed
from the semaphore queue in which it is suspended.
Deadlock and Starvation Solution?What is a transaction? A
transaction is a list of operations When the system begins to
execute the list, it must execute all of them without interruption,
or It must not execute any at all Example: List manipulator Add or
delete an element from a list Adjust the list descriptor, e.g.,
length Too heavyweight need something simpler
12
Well-known Problems of SynchronizationBounded-Buffer Problem
Readers and Writers Problem Dining-Philosophers Problem
Bounded-Buffer Problem N buffers, each can hold one item
Semaphore mutex initialized to the value 1 Semaphore full
initialized to the value 0 Semaphore empty initialized to the value
N.
BUFFER
13
Bounded-Buffer Problem N buffers, each can hold one item
Semaphore mutex initialized to the value 1 Semaphore full
initialized to the value 0 Semaphore empty initialized to the value
N.
BUFFER
Bounded Buffer Problem (Cont.) The structure of the producer
process do { // produce an item wait (empty); wait (mutex); // add
the item to the buffer signal (mutex); signal (full); } while
(true);
14
Bounded Buffer Problem (Cont.) The structure of the consumer
process do { wait (full); wait (mutex); // remove an item from
buffer signal (mutex); signal (empty); // consume the removed item
} while (true);
Readers-Writers Problem A data set is shared among a number of
concurrent processes Readers only read the data set; they do not
perform any updates Writers can both read and write. Problem allow
multiple readers to read at the same time. Only one single writer
can access the shared data at the same time. Shared Data Data set
Semaphore mutex initialized to 1. Semaphore wrt initialized to 1.
Integer readcount initialized to 0.
15
Readers-Writers Problem (Cont.) The structure of a writer
process do { wait (wrt) ; // writing is performed
signal (wrt) ; } while (true)
Readers-Writers Problem (Cont.) The structure of a reader
process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait
(wrt) ; signal (mutex) // reading is performed wait (mutex) ;
readcount - - ; if readcount == 0) signal (wrt) ; signal (mutex) ;
} while (true)
16
Readers-Writers LocksGeneralized to provide reader-writer locks
on some systems. Most useful in following situations: 1. In apps
where it is easy to identify which processes only read shared data
and which only write shared data. 2. In apps with more readers than
writers. More overhead to create reader-writer lock than plain
semaphores.
Dining-Philosophers Problem Shared data Bowl of rice (data set)
Semaphore chopstick[5] initialized to 1
17
Dining-Philosophers Problem (Cont.) The structure of Philosopher
i :Do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); //
eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); //
think } while (true) ;
Dining-Philosophers Problem (Cont.) The structure of Philosopher
i :Do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); //
eat
DEADLOCK POSSIBLE
signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); //
think } while (true) ;
18
Problems with Semaphores Incorrect use of semaphore
operations: signal (mutex) . wait (mutex)No mutual exclusion
wait (mutex) wait (mutex)Deadlock
Omitting of wait (mutex) or signal (mutex) (or both)Either no
mutual exclusion or deadlock
Monitors A high-level abstraction that provides a convenient and
effective mechanism for process synchronization Only one process
may be active within the monitor at a timemonitor monitor-name { //
shared variable declarations procedure P1 () { . } procedure Pn ()
{} Initialization code ( .) { } } }
19
Schematic view of a Monitor
Condition Variables condition x, y; Two operations on a
condition variable: x.wait () a process that invokes the operation
is suspended. x.signal () resumes one of processes (if any) that
invoked x.wait ()
20
Condition Variables If Q is signaled to continue then P must
wait: Note: remember only one process in monitor at a time
Possible scenarios: Signal and wait: P waits for Q to leave or
suspend Signal and continue: Q waits for P to leave or suspend
Monitor with Condition Variables
21
Solution to Dining Philosophersmonitor DP { enum { THINKING;
HUNGRY, EATING) state [5] ; condition self [5]; void pickup (int i)
{ state[i] = HUNGRY; test(i); if (state[i] != EATING) self
[i].wait; } void putdown (int i) { state[i] = THINKING; // test
left and right neighbors test((i + 4) % 5); test((i + 1) % 5);
}dp.pickup(i); Eat dp.putdown(i);
Solution to Dining Philosophers (cont)void test (int i) { if (
(state[(i + 4) % 5] != EATING) && (state[i] == HUNGRY)
&& (state[(i + 1) % 5] != EATING) ) { state[i] = EATING ;
self[i].signal () ; } } initialization_code() { for (int i = 0; i
< 5; i++) state[i] = THINKING; } }
22
Java Monitors Every object in Java has associate with it a
single lock A method declared synchronized means calling the method
means capturing the lock for the object.public class SimpleClass {
public synchronized void safeMethod() {
Java Monitors Every object in Java has associate with it a
single lock A method declared synchronized means calling the method
means capturing the lock for the object.public class SimpleClass {
public synchronized void safeMethod() {
SimpleClass sc = new SimpleClass();
23
Synchronization Examples Windows XP Linux Pthreads
Windows XP Synchronization Uses interrupt masks to protect
access to global resources on uniprocessor systems Uses spinlocks
on multiprocessor systems Also provides dispatcher objects which
may act as either mutexes and semaphores Dispatcher objects may
also provide events An event acts much like a condition
variable
24
Linux Synchronization Linux: disables interrupts to implement
short critical sections
Linux provides: semaphores spin locks
Pthreads Synchronization Pthreads API is OS-independent It
provides: mutex locks condition variables
Non-portable extensions include: read-write locks spin locks
25
Slide 8-1
Basic Synchronization Principles
Concurrency Value of concurrency speed & economics But few
widely-accepted concurrent programming languages (Java, C# are
exceptions) Few concurrent programming paradigm Each problem
requires careful consideration There is no common model
Slide 8-2
OS tools to support concurrency tend to be low level
1
Command ExecutionEnter Loop Another Command? No Yes fork()code
Enter Loop Another Command? No
Slide 8-3
Exit Loop Yes
Exit Loop
CreateProcess()code
Execute Command Wait for Child to Terminate
Execute Command
Execute Command
UNIX Shell
Windows Command Launch
Synchronizing Multiple Threads with a Shared
VariableInitialize
Slide 8-4
CreateThread() Wait runTime seconds Thread Work
TRUE
TRUE
FALSE
FALSE
runFlag=FALSE Exit
Terminate
FALSE
runFlag?
TRUE
2
Traffic Intersections
Slide 8-5
Critical Sectionsshared double balance;
Slide 8-6
Code for p1. . . balance = balance + amount; amount; . . .
Code for p2. . . balance = balance . . .
balance+=amount balance
balance-=amount
3
Critical SectionsExecution of p1 load R1, balance load R2,
amount Timer interrupt Execution of p2
Slide 8-7
Timer interrupt add R1, R2 store R1, balance
load load sub store
R1, R2, R1, R1,
balance amount R2 balance
Critical Sections Mutual exclusion: Only one process can be in
the critical section at a time There is a race to execute critical
sections (race condition) The sections may be defined by different
code in different processes cannot easily detect with static
analysis
Slide 8-8
Without mutual exclusion, results of multiple execution are not
determinate Need an OS mechanism so programmer can resolve
races
4
Slide 8-9
Critical Sections Mutual exclusion: Only one process can be in
the critical section at a time There is a race to execute critical
sections The sections may be defined by different code in different
processes cannot easily detect with static analysis
Without mutual exclusion, results of multiple execution are not
determinate Need an OS mechanism so programmer can resolve
races
Some Possible Solutions Disable interrupts Software solution
locks Transactions FORK(), JOIN(), and QUIT(
Slide 8-10
Terminate processes with QUIT() to synchronize Create processes
whenever critical section is complete
something new
5
Slide 8-11
Disabling Interruptsshared double balance;
Code for p1
disableInterrupts(); balance = balance + amount; amount;
enableInterrupts();
disableInterrupts(); balance = balance enableInterrupts();
Code for p2
Interrupts could be disabled arbitrarily long Really only want
to prevent p1 and p2 from interfering with one another; this blocks
all pi Try using a shared lock variable
Using a Lock Variableshared boolean lock = FALSE; shared double
balance;
Slide 8-12
Code for p1
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /*
Execute critical sect */ balance = balance + amount; /* Release
lock */ lock = FALSE;
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /*
Execute critical sect */ balance = balance - amount; /* Release
lock */ lock = FALSE;
Code for p2
6
Busy Wait Conditionshared boolean lock = FALSE; shared double
balance;
Slide 8-13
Code for p1
p1
lock = TRUE
Interrupt
lock = FALSE
p2
Interrupt
Blocked at while
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; / /*
Execute critical sect */ balance = balance + amount; /* Release
lock */ lock = FALSE;
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /*
Execute critical sect */ balance = balance - amount; /* Release
lock */ lock = FALSE;
Code for p2
Unsafe Solutionshared boolean lock = FALSE; shared double
balance;
Interrupt
Slide 8-14
Code for p1
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /*
Execute critical sect */ balance = balance + amount; /* Release
lock */ lock = FALSE;
/* Acquire the lock */ while(lock){NULL;} lock = TRUE; /*
Execute critical sect */ balance = balance - amount; /* Release
lock */ lock = FALSE;
Code for p2
Worse yet another race condition Is it possible to solve the
problem?
7
Atomic Lock Manipulationenter(lock) { disableInterrupts(); /*
Loop until lock is TRUE */ while(lock) { /* Let interrupts occur */
enableInterrupts(); disableInterrupts(); } lock = TRUE;
enableInterrupts(); } exit(lock) { disableInterrupts(); lock =
FALSE; enableInterrupts(); }
Slide 8-15
Bound the amount of time that interrupts are disabled Can
include other code to check that it is OK to assign a lock but this
is still overkill
Atomic Lock Manipulationshared int lock = FALSE; shared double
amount,balance;
Slide 8-16
Code for p1
/* Acquire the lock */ enter(lock); /* Execute critical sect */
balance = balance + amount; /* Release lock */ exit(lock);
/* Acquire the lock */ enter(lock); /* Execute critical sect */
balance = balance - amount; /* Release lock */ exit(lock);
Code for p2
Bound the amount of time that interrupts are disabled Can
include other code to check that it is OK to assign a lock but this
is still overkill
8
Slide 8-17
Deadlocked Pirates
Deadlock (2)shared boolean lock1 = FALSE; shared boolean lock2 =
FALSE; shared list L;
Slide 8-18
Code for p1
. . . /* Enter CS to delete elt */ enter(lock1); ; ; /* Enter CS
to update len */ enter(lock2); ; /* Exit both CS */ exit(lock1);
exit(lock2); . . .
. . . /* Enter CS to update len */ enter(lock2); ; /* Enter CS
to add elt */ enter(lock1); ; /* Exit both CS */ exit(lock2);
exit(lock1); . . .
Code for p2
9
Processing Two Componentsshared boolean lock1 = FALSE; shared
boolean lock2 = FALSE; shared list L;
Slide 8-19
Code for p1
. . . /* Enter CS to delete elt */ enter(lock1); ; /* Exit CS */
exit(lock1); ; /* Enter CS to update len */ enter(lock2); ; /* Exit
CS */ exit(lock2); . . .
. . . /* Enter CS to update len */ enter(lock2); ; /* Exit CS */
exit(lock2); /* Enter CS to add elt */ enter(lock1); ; /* Exit CS
*/ exit(lock1); . . .
Code for p2
Transactions A transaction is a list of operations When the
system begins to execute the list, it must execute all of them
without interruption, or It must not execute any at all
Slide 8-20
Example: List manipulator Add or delete an element from a list
Adjust the list descriptor, e.g., length
Too heavyweight need something simpler
10
A Semaphore
Slide 8-21
Dijkstra Semaphore
Slide 8-22
Invented in the 1960s Conceptual OS mechanism, with no specific
implementation defined (could be enter()/exit()) Basis of all
contemporary OS synchronization mechanisms
11
Solution Constraints
Slide 8-23
Processes p0 & p1 enter critical sections Mutual exclusion:
Only one process at a time in the CS Only processes competing for a
CS are involved in resolving who enters the CS Once a process
attempts to enter its CS, it cannot be postponed indefinitely After
requesting entry, only a bounded number of other processes may
enter before the requesting process
Notation Let fork(proc, N, arg1, arg2, , argN)be a command to
create a process, and to have it execute using the given N
arguments Canonical problem:Proc_0() { while(TRUE) { ; ; } }
fork(proc_0, 0); fork(proc_1, 0);
Slide 8-24
proc_1() { while(TRUE { ; ; } }
12
Solution Assumptions Memory read/writes are indivisible
(simultaneous attempts result in some arbitrary order of access)
There is no priority among the processes Relative speeds of the
processes/processors is unknown Processes are cyclic and
sequential
Slide 8-25
Dijkstra Semaphore Definition
Slide 8-26
Classic paper describes several software attempts to solve the
problem (see problem 4, Chapter 8) Found a software solution, but
then proposed a simpler hardware-based solution A semaphore, s, is
a nonnegative integer variable that can only be changed or tested
by these two indivisible functions:V(s): [s = s + 1] P(s): [while(s
== 0) {wait}; s = s - 1]
13
Solving the Canonical ProblemProc_0() { while(TRUE) { ;
P(mutex); ; V(mutex); } } semaphore mutex = 1; fork(proc_0, 0);
fork(proc_1, 0);
Slide 8-27
proc_1() { while(TRUE { ; P(mutex); ; V(mutex); } }
Shared Account Balance ProblemProc_0() { . . . /* Enter the CS
*/ P(mutex); balance += amount; V(mutex); . . . } semaphore mutex =
1; fork(proc_0, 0); fork(proc_1, 0);
Slide 8-28
proc_1() { . . . /* Enter the CS */ P(mutex); balance -= amount;
V(mutex); . . . }
14
Sharing Two Variablesproc_A() { while(TRUE) { ; update(x); /*
Signal proc_B */ V(s1); ; /* Wait for proc_B */ P(s2); retrieve(y);
} } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0);
fork(proc_B, 0);
Slide 8-29
proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1);
retrieve(x); ; update(y); /* Signal proc_A */ V(s2); ; } }
Device Controller Synchronization
Slide 8-30
The semaphore principle is logically used with the busy and done
flags in a controller Driver signals controller with a V(busy),
then waits for completion with P(done) Controller waits for work
with P(busy), then announces completion with V(done)
15
Bounded Buffer ProblemEmpty Pool
Slide 8-31
Producer
Consumer
Full Pool
Bounded Buffer Problem (2)
Slide 8-32
producer() { consumer() { buf_type *next, *here; buf_type *next,
*here; while(TRUE) { while(TRUE) { produce_item(next); /* Claim
full buffer */ /* Claim an empty */ P(mutex); P(empty); P(full);
P(mutex); here = obtain(full); here = obtain(empty); V(mutex);
V(mutex); copy_buffer(here, next); copy_buffer(next, here);
P(mutex); P(mutex); release(here, emptyPool); release(here,
fullPool); V(mutex); V(mutex); /* Signal an empty buffer */ /*
Signal a full buffer */ V(empty); V(full); consume_item(next); } }
} } semaphore mutex = 1; semaphore full = 0; /* A general
(counting) semaphore */ semaphore empty = N; /* A general
(counting) semaphore */ buf_type buffer[N]; fork(producer, 0);
fork(consumer, 0);
16
Bounded Buffer Problem (3)
Slide 8-33
producer() { consumer() { buf_type *next, *here; buf_type *next,
*here; while(TRUE) { while(TRUE) { produce_item(next); /* Claim
full buffer */ /* Claim an empty */ P(full); P(empty); P(mutex);
P(mutex); here = obtain(full); here = obtain(empty); V(mutex);
V(mutex); copy_buffer(here, next); copy_buffer(next, here);
P(mutex); P(mutex); release(here, emptyPool); release(here,
fullPool); V(mutex); V(mutex); /* Signal an empty buffer */ /*
Signal a full buffer */ V(empty); V(full); consume_item(next); } }
} } semaphore mutex = 1; semaphore full = 0; /* A general
(counting) semaphore */ semaphore empty = N; /* A general
(counting) semaphore */ buf_type buffer[N]; fork(producer, 0);
fork(consumer, 0);
Readers-Writers Problem
Slide 8-34
Writers Readers
17
Readers-Writers Problem (2)Writer Writer Writer Writer Writer
Writer Writer
Slide 8-35
Reader Reader Reader Reader Reader Reader Reader Reader
Shared Resource
Readers-Writers Problem (3)Writer Writer Writer Writer Writer
Writer Writer Reader Reader Reader Reader Reader Reader Reader
Reader Shared Resource
Slide 8-36
18
Readers-Writers Problem (4)Reader Reader Reader Reader Reader
Reader Reader Reader Writer Writer Writer Writer Writer Writer
Slide 8-37
Writer Shared Resource
First Solutionreader() { while(TRUE) { ; P(mutex); readCount++;
if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */
access(resource); P(mutex); readCount--; if(readCount == 0)
V(writeBlock); V(mutex); } } resourceType *resource; int readCount
= 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader,
0); fork(writer, 0);
Slide 8-38
writer() { while(TRUE) { ; P(writeBlock); /* Critical section */
access(resource); V(writeBlock); } }
First reader competes with writers Last reader signals
writers
19
First Solution (2)reader() { while(TRUE) { ; P(mutex);
readCount++; if(readCount == 1) P(writeBlock); V(mutex); /*
Critical section */ access(resource); P(mutex); readCount--;
if(readCount == 0) V(writeBlock); V(mutex); } } resourceType
*resource; int readCount = 0; semaphore mutex = 1; semaphore
writeBlock = 1; fork(reader, 0); fork(writer, 0);
Slide 8-39
writer() { while(TRUE) { ; P(writeBlock); /* Critical section */
access(resource); V(writeBlock); } }
First reader competes with writers Last reader signals writers
Any writer must wait for all readers Readers can starve writers
Updates can be delayed forever May not be what we want
reader() { while(TRUE) { ;
Writer Precedence { writer()
Slide 8-40
4 2
1
P(readBlock); P(mutex1); readCount++; if(readCount == 1)
P(writeBlock); V(mutex1); V(readBlock); access(resource);
P(mutex1); readCount--; if(readCount == 0) V(writeBlock);
V(mutex1);
while(TRUE) { ; P(mutex2); writeCount++; if(writeCount == 1)
P(readBlock); 3 V(mutex2); P(writeBlock); access(resource);
V(writeBlock); P(mutex2) writeCount--; if(writeCount == 0)
V(readBlock); V(mutex2); } }
} } int readCount = 0, writeCount = 0; semaphore mutex = 1,
mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending =
1; fork(reader, 0); fork(writer, 0);
20
Writer Precedence (2)
Slide 8-41
reader() { writer() { while(TRUE) { while(TRUE) { ; ; P(mutex2);
4 P(writePending); P(readBlock); writeCount++; P(mutex1);
if(writeCount == 1) readCount++; P(readBlock); 3 if(readCount == 1)
V(mutex2); 2 P(writeBlock); P(writeBlock); V(mutex1);
access(resource); V(readBlock); V(writeBlock); 1 V(writePending);
P(mutex2) access(resource); writeCount--; P(mutex1); if(writeCount
== 0) readCount--; V(readBlock); if(readCount == 0) V(mutex2);
V(writeBlock); } V(mutex1); } } } int readCount = 0, writeCount =
0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1,
writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer,
0);
The Sleepy Barber Barber can cut one persons hair at a time
Other customers wait in a waiting roomEntrance to Waiting Room
(sliding door) Shop Exit Entrance to Barbers Room (sliding
door)
Slide 8-42
Waiting Room
21
Sleepy Barber (aka Bounded Buffer)customer() { while(TRUE) {
customer = nextCustomer(); if(emptyChairs == 0) continue; P(chair);
P(mutex); emptyChairs--; takeChair(customer); V(mutex);
V(waitingCustomer); } }
Slide 8-43
barber() { while(TRUE) { P(waitingCustomer); P(mutex);
emptyChairs++; takeCustomer(); V(mutex); V(chair); } }
semaphore mutex = 1, chair = N, waitingCustomer = 0; int
emptyChairs = N; fork(customer, 0); fork(barber, 0);
Cigarette Smokers Problem Three smokers (processes) Each wish to
use tobacco, papers, & matches Only need the three resources
periodically Must have all at once
Slide 8-44
3 processes sharing 3 resources Solvable, but difficult
22
Implementing Semaphores
Slide 8-45
Minimize effect on the I/O system Processes are only blocked on
their own critical sections (not critical sections that they should
not care about) If disabling interrupts, be sure to bound the time
they are disabled
Implementing Semaphores: enter() & exit()class semaphore {
int value; public: semaphore(int v = 1) { value = v;}; P(){
disableInterrupts(); while(value == 0) { enableInterrupts();
disableInterrupts(); } value--; enableInterrupts(); }; V(){
disableInterrupts(); value++; enableInterrupts(); }; };
Slide 8-46
23
Implementing Semaphores: Test and Set InstructionData CC
Register Register Data CC Register Register
Slide 8-47
TS(m): [Reg_i = memory[m]; memory[m] = TRUE;]
R3
R3
FALSE
=0
m
FALSE
m
TRUE
Primary Memory
Primary Memory
(a) Before Executing TS
(b) After Executing TS
Using the TS Instruction
Slide 8-48
boolean s = FALSE; . . . while(TS(s)) ; s = FALSE; . . .
semaphore s = 1; . . . P(s) ; V(s); . . .
24
Implementing the General Semaphorestruct semaphore { int value =
; boolean mutex = FALSE; boolean hold = TRUE; }; shared struct
semaphore s; P(struct semaphore s) { while(TS(s.mutex)) ;
s.value--; if(s.value < 0) ( s.mutex = FALSE; while(TS(s.hold))
; } else s.mutex = FALSE; }
Slide 8-49
V(struct semaphore s) { while(TS(s.mutex)) ; s.value++;
if(s.value =1)&& &&(S[N-1]>=1)) { for(i=0; i0) {
goto L1; R_num--; } else { dequeue(R_wait); // Release a thread
S_num++; enqueue(CallingThread, S_wait); } if(S_num>0) {
V(mutex); S_num--; goto L1; dequeue(S_wait); // Release a thread }
} } V(mutex); } }
7
Slide 9-15
Dining Philosophers Problemphilosopher(int i) { while(TRUE) { //
Think // Eat Psim(fork[i], fork [(i+1) mod 5]); eat();
Vsim(fork[i], fork [(i+1) mod 5]); } } semaphore fork[5] =
(1,1,1,1,1); fork(philosopher, 1, 0); fork(philosopher, 1, 1);
fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher,
1, 4);
Events
Slide 9-16
Exact definition is specific to each OS A process can wait on an
event until another process signals the event Have event descriptor
(event control block) Active approach Multiple processes can wait
on an event Exactly one process is unblocked when a signal occurs A
signal with no waiting process is ignored
May have a queue function that returns number of processes
waiting on the event
8
Exampleclass Event { public: void signal(); void wait() int
queue(); }
Slide 9-17
wait()
1
shared Event topOfHour; . . . // Wait until the top of the hour
before proceding topOfHour.wait(); // Its the top of the hour
...
ResumetopOfHour
3
2signal()
shared Event topOfHour; . . . while(TRUE) if(isTopOfHour())
while(topOfHour.queue() > 0) topOfHour.signal(); } . . .
UNIX Signals A UNIX signal corresponds to an event
Slide 9-18
It is raised by one process (or hardware) to call another
processs attention to an event It can be caught (or ignored) by the
subject process
Justification for including signals was for the OS to inform a
user process of an event User pressed delete key Program tried to
divide by zero Attempt to write to a nonexistent pipe etc.
9
More on Signals Each version of UNIX has a fixed set of signals
(Linux has 31 of them) signal.h defines the signals in the OS App
programs can use SIGUSR1 & SIGUSR2 for arbitrary signalling
Raise a signal with kill(pid, signal) Process can let default
handler catch the signal, catch the signal with own code, or cause
it to be ignored
Slide 9-19
More on Signals (cont) OS signal system call
Slide 9-20
To ignore: signal(SIG#, SIG_IGN) To reinstate default:
signal(SIG#, SIG_DFL) To catch: signal(SIG#, myHandler)
Provides a facility for writing your own event handlers in the
style of interrupt handlers
10
Slide 9-21
Signal Handling/* code for process p */ . . . signal(SIG#,
myHndlr); . . . /* ARBITRARY CODE */ void myHndlr(...) { /*
ARBITRARY CODE */ }
Signal Handling/* code for process p */ . . . signal(SIG#,
sig_hndlr); . . . /* ARBITRARY CODE */
Slide 9-22
void sig_hndlr(...) { /* ARBITRARY CODE */ }
An executing process, q Raise SIG# for p q is blocked q resumes
executionsig_hndlr runs in
ps address space
11
Using UNIX SignalsPis Address Space Pis Execution
Slide 9-23
Pjs Execution
program Pis Signal Handler signal hndlr data stack &
heap
Toy Signal Handler
Slide 9-24
#include static void sig_handler(int); int main () { int i,
parent_pid, child_pid, status; if(signal(SIGUSR1, sig_handler) ==
SIG_ERR) printf(Parent: Unable to create handler for SIGUSR1\n);
if(signal(SIGUSR2, sig_handler) == SIG_ERR) printf(Parent: Unable
to create handler for SIGUSR2\n); parent_pid = getpid();
if((child_pid = fork()) == 0) { kill(parent_pid, SIGUSR1); for (;;)
pause(); } else { kill(child_pid, SIGUSR2); printf(Parent:
Terminating child \n); kill(child_pid), SIGTERM);
wait(&status); printf(done\n); } }
12
Toy Signal Handler (2)static void sig_handler(int signo) {
switch(signo) { case SIGUSR1: /* Incoming SIGUSR1 */ printf(Parent:
Received SIGUSER1\n); break; case SIGUSR2: /* Incoming SIGUSR2 */
printf(Child: Received SIGUSER2\n); break; default: break; } return
}
Slide 9-25
Monitors Specialized form of ADT Encapsulates implementation
Public interface (types & functions)
Slide 9-26
Only one process can be executing in the ADT at a time monitor
anADT {semaphore mutex . . . public: proc_i() { P(mutex); // ;
Implicit
13
Example: Shared Balancemonitor sharedBalance { double balance;
public: credit(double amount) {balance += amount;}; debit(double
amount) {balance -= amount;}; . . . };
Slide 9-27
Example: Readers & Writers
Slide 9-28
monitor readerWriter_1 { int numberOfReaders = 0; int
numberOfWriters = 0; boolean busy = FALSE; public: startRead() {
reader(){ writer(){ }; while(TRUE) { while(TRUE) { finishRead() { .
. . . . . }; startRead(); startWriter(); startWrite() {
finishRead(); finishWriter(); }; . . . . . . finishWrite() { } } };
fork(reader, 0); }; . . . fork(reader, 0): fork(writer, 0); . . .
fork(writer, 0);
14
Example: Readers & Writers
Slide 9-29
monitor readerWriter_1 { int numberOfReaders = 0; int
numberOfWriters = 0; boolean busy = FALSE; public: startWrite() {
startRead() { numberOfWriters++; while(numberOfWriters != 0) ;
while( numberOfReaders++; busy || }; (numberOfReaders > 0)
finishRead() { ) ; numberOfReaders-; busy = TRUE; }; };
finishWrite() { numberOfWriters--; busy = FALSE; }; };
Slide 9-30
Example: Readers & Writersmonitor readerWriter_1 { Deadlock
can happen int numberOfReaders = 0; int numberOfWriters = 0;
boolean busy = FALSE; public: startWrite() { startRead() {
numberOfWriters++; while(numberOfWriters != 0) ; while(
numberOfReaders++; busy || }; (numberOfReaders > 0) finishRead()
{ ) ; numberOfReaders--; busy = TRUE; }; }; finishWrite() {
numberOfWriters--; busy = FALSE; }; };
15
Sometimes Need to Suspend Process obtains monitor, but detects a
condition for which it needs to wait Want special mechanism to
suspend until condition is met, then resume Process that makes
condition true must exit monitor Suspended process then resumes
Slide 9-31
Condition Variable
Condition Variables
Slide 9-32
Essentially an event (as defined previously) Occurs only inside
a monitor Operations to manipulate condition variable wait: Suspend
invoking process until another
executes a signal signal: Resume one process if any are
suspended, otherwise do nothing queue: Return TRUE if there is at
least one process suspended on the condition variable
16
Active vs Passive signal p0 executes signal while p1 is waiting
p0 yields the monitor to p1 The signal is only TRUE the instant it
happens
Slide 9-33
Hoare semantics: same as active semaphore
Brinch Hansen (Mesa) semantics: same as passive semaphore p0
executes signal while p1 is waiting p0 continues to execute, then
when p0 exits the monitor p1 can receive the signal Used in the
Xerox Mesa implementation
Hoare vs Mesa Semantics Hoare semantics:
Slide 9-34
. . . if(resourceNotAvailable()) resourceCondition.wait(); /*
now available continue */ . . .
Mesa semantics:. . . while(resourceNotAvailable())
resourceCondition.wait(); /* now available continue */ . . .
17
2nd Try at Readers & Writers
Slide 9-35
monitor readerWriter_2 { int numberOfReaders = 0; boolean busy =
FALSE; condition okToRead, okToWrite; public: startWrite() {
startRead() { if(busy || (okToWrite.queue()) if((numberOfReaders !=
0) || busy) okToRead.wait(); okToWrite.wait(); numberOfReaders++;
busy = TRUE; okToRead.signal(); }; }; finishWrite() { finishRead()
{ busy = FALSE; numberOfReaders--; if(okToRead.queue())
if(numberOfReaders == 0) okToRead.signal() okToWrite.signal(); else
}; okToWrite.signal() }; };
Example: Synchronizing Traffic One-way tunnel Can only use
tunnel if no oncoming traffic OK to use tunnel if traffic is
already flowing the right way
Slide 9-36
18
Example: Synchronizing Traffic
Slide 9-37
monitor tunnel { int northbound = 0, southbound = 0;
trafficSignal nbSignal = RED, sbSignal = GREEN; condition busy;
public: nbArrival() { if(southbound > 0) busy.wait();
northbound++; nbSignal = GREEN; sbSignal = RED; }; sbArrival() {
if(northbound > 0) busy.wait(); southbound++; nbSignal = RED;
sbSignal = GREEN; }; depart(Direction exit) ( if(exit = NORTH {
northbound--; if(northbound == 0) while(busy.queue())
busy.signal(); else if(exit == SOUTH) { southbound--; if(southbound
== 0) while(busy.queue()) busy.signal(); } } }
Dining Philosophers again ...#define N ___ enum status(EATING,
HUNGRY, THINKING}; monitor diningPhilosophers { status state[N];
condition self[N]; test(int i) { if((state[(i-1) mod N] != EATING)
&& (state[i] == HUNGRY) && (state[(i+1) mod N] !=
EATING)) { state[i] = EATING; self[i].signal(); } }; public:
diningPhilosophers() { // Initilization for(int i = 0; i < N;
i++) state[i] = THINKING; };
Slide 9-38
19
Dining Philosophers again ...test(int i) { if((state[(i-1) mod
N] != EATING) && (state[i] == HUNGRY) &&
(state[(i+1) mod N] != EATING)) { state[i] = EATING;
self[i].signal(); }; }; public: diningPhilosophers() {...};
pickUpForks(int i) { state[i] = HUNGRY; test(i); if(state[i] !=
EATING) self[i].wait(); }; putDownForks(int i) { state[i] =
THINKING; test((i-1) mod N); test((i+1) mod N); }; }
Slide 9-39
Experience with Monitors Danger of deadlock with nested calls
Monitors were implemented in Mesa Used Brinch Hansen semantics
Nested monitor calls are, in fact, a problem Difficult to get the
right behavior with these semantics Needed timeouts, aborts,
etc.
Slide 9-40
20
Interprocess Communication (IPC) Different processes - no shared
memory space IPC - a way for different processes to communicate
even if they exist on different machines OS copies info from
sending process memory space to receiving process memory space
Slide 9-41
IPC MechanismsMessage OS IPC Mechanism
Slide 9-42
Info copy
Info to be shared Address Space for p0
Address Space for p1
Must bypass memory protection mechanism for local copies Must be
able to use a network for remote copies
21
Refined IPC Mechanism Spontaneous changes to p1s address space
Avoid through the use of mailboxesAddress Space for p0 Mailbox for
p1 Info to be sharedsend( p1, );
Slide 9-43
Address Space for p1
Message Message Message
Info copyreceive();
OS Interfacesend function receive function
Slide 9-44
OS manages the mailbox space More secure message systemAddress
Space for p0 Info to be sharedsend( p1, );
Refined IPC MechanismAddress Space for p1 Info copy OS Interface
Mailbox for p1receive();
send function
Message Message Message
receive function
22
Interprocess Communication (IPC)
Slide 9-45
Signals, semaphores, etc. do not pass information from one
process to another Monitors support information sharing, but only
through shared memory in the monitor There may be no shared memory
OS does not support it Processes are on different machines on a
network
Can use messages to pass info while synchronizing
Message Protocols Sender transmits a set of bits to receiver
Slide 9-46
How does the sender know when the receiver is ready (or when the
receiver obtained the info)? How does the receiver know how to
interpret the info? Need a protocol for communication Standard
envelope for containing the info Standard header
A message system specifies the protocols
23
Transmit Operations Asynchronous send:
Slide 9-47
Delivers message to receivers mailbox Continues execution No
feedback on when (or if) info was delivered
Synchronous send: Goal is to block sender until message is
received by a process Variant sometimes used in networks: Until the
message is in the mailbox
Receive Operation Blocking receive: Return the first message in
the mailbox If there is no message in mailbox, block the receiver
until one arrives
Slide 9-48
Nonblocking receive: Return the first message in the mailbox If
there is no message in mailbox, return with an indication to that
effect
24
Synchronized IPCCode for p1/* signal p2 */ syncSend(message1,
p2); ; /* wait for signal from p2 */ blockReceive(msgBuff,
&from);
Slide 9-49
Code for p2/* wait for signal from p1 */ blockReceive(msgBuff,
&from); ; /* signal p1 */ syncSend(message2, p1);
syncSend()
blockReceive()
blockReceive()
syncSend()
Slide 9-50
Asynchronous IPCCode for p1 Code for p2/* signal p2 */ /* test
for signal from p1 */ asyncSend(message1, p2);
if(nbReceive(&msg, &from)) { ; ; /* wait for signal from p2
*/ asyncSend(message2, p1); while(!nbReceive(&msg, &from));
}else< ; }nonblockReceive() asyncSend() nonblockReceive()
nonblockReceive() asyncSend() nonblockReceive()
25
UNIX Pipes
Slide 9-51
Address Space for p1 Info to be sharedwrite(pipe[1], );
Info copy System Call Interface pipe for p1 and
p2read(pipe[0]);
write function
read function
UNIX Pipes (cont) The pipe interface is intended to look like a
file interface Analog of open is to create the pipe File read/write
system calls are used to send/receive information on the pipe
Slide 9-52
What is going on here? Kernel creates a buffer when pipe is
created Processes can read/write into/out of their address spaces
from/to the buffer Processes just need a handle to the buffer
26
File handles are copied on fork so are pipe handles
UNIX Pipes (cont)
Slide 9-53
int pipeID[2]; . . . pipe(pipeID); . . . if(fork() == 0) { /*
the child */ . . . read(pipeID[0], childBuf, len); ; . . . } else {
/* the parent */ . . . write(pipeID[1], msgToChild, len); . . .
}
The normal write is an asynchronous op (that notifies of write
errors) The normal read is a blocking read The read operation can
be nonblocking#include . . . int pipeID[2]; . . . pipe(pipeID);
ioctl(pipeID[0], FIONBIO, &on); . . . read(pipeID[0], buffer,
len); if(errno != EWOULDBLOCK) { /* no data */ } else { /* have
data */
UNIX Pipes (cont)
Slide 9-54
27
Source, Filter and Sink Processes
Slide 9-55
Source
Filter
Sink
Information Flow Through UNIX Pipes
Slide 9-56
Address Space for p1 Info to be sharedwrite(pipe[1], );
Info copy System Call Interface pipe for p1 and
p2read(pipe[0]);
write function
read function
28
DeadlocksGordon College Stephen Brinton
Deadlock Overview The Deadlock Problem System Model Deadlock
Characterization Methods for Handling Deadlocks
Deadlock Prevention Deadlock Avoidance Deadlock Detection
Recovery from DeadlockObjectives To develop a description of
deadlocks (prevent sets of concurrent processes from completing
their tasks) To present a number of different methods for
preventing or avoiding deadlocks in a computer system.
1
The Deadlock Problem A set of blocked processes each holding a
resource and waiting to acquire a resource held by another process
in the set. Example System has 2 tape drives. P1 and P2 each hold
one tape drive and each needs another one. Example semaphores A and
B, initialized to 1P0 wait (A); wait (B); P1 wait(B) wait(A)
Bridge Crossing Example
Traffic only in one direction. Each section of a bridge can be
viewed as a resource. If a deadlock occurs, it can be resolved if
one car backs up (preempt resources and rollback). Several cars may
have to be backed up if a deadlock occurs. Starvation is
possible.
2
System Model Resource types R1, R2, . . ., RmCPU cycles, memory
space, I/O devices
Each resource type Ri has Wi instances. Each process utilizes a
resource as follows: request use release
Deadlock CharacterizationDeadlock can arise if four conditions
hold simultaneously.
1. Mutual exclusion: only one process at a timecan use a
resource.
2. Hold and wait: a process holding at least one 3. No
preemption: a resource can be released
resource is waiting to acquire additional resources held by
other processes. only voluntarily by the process holding it, after
that process has completed its task. of waiting processes such that
P0 is waiting for a resource that is held by P1, P1 is waiting for
a resource that is held by P2, , Pn1 is waiting for a resource that
is held by Pn, and Pn is waiting for a resource that is held by
P0.
4. Circular wait: there exists a set {P0, P1, , P0}
3
Resource-Allocation GraphA set of vertices V and a set of edges
E.
V is partitioned into two types: P = {P1, P2, , Pn}, the set
consisting of all the processes in the system. R = {R1, R2, , Rm},
the set consisting of all resource types in the system. request
edge directed edge P1 Rj
assignment edge
directed edge Rj Pi
Resource-Allocation Graph (Cont.) Process Resource Type with 4
instances
Pi requests instance of Rj
PiRj
Pi is holding an instance of Rj
PiRj
4
Resource Allocation Graph 1
Is there a deadlock in this graph?
Resource Allocation Graph 2
Is there a deadlock in this graph?
5
Resource Allocation Graph 3
Is there a deadlock in this graph?
Basic Facts If graph contains no cycles no deadlock. If graph
contains a cycle if only one instance per resource type, then
deadlock. if several instances per resource type, possibility of
deadlock.
6
Methods for Handling Deadlocks1. Ensure that the system will
never enter a deadlock state. 2. Allow the system to enter a
deadlock state and then recover. 3. Ignore the problem and pretend
that deadlocks never occur in the system; used by most operating
systems, including UNIX and Windows.
Deadlock PreventionRestrain the ways request can be made.
Mutual Exclusion not required for
sharable resources; must hold for nonsharable resources. Hold
and Wait must guarantee that whenever a process requests a
resource, it does not hold any other resources. Require process to
request and be allocated all its resources before it begins
execution, or allow process to request resources only when the
process has none. Low resource utilization; starvation
possible.
7
Deadlock Prevention (Cont.) No Preemption If a process that is
holding some resources requests another resource that cannot be
immediately allocated to it, then all resources currently being
held are released. Preempted resources are added to the list of
resources for which the process is waiting. Process will be
restarted only when it can regain its old resources, as well as the
new ones that it is requesting.
Circular Wait impose a total ordering of
all resource types, and require that each process requests
resources in an increasing order of enumeration.
Deadlock AvoidanceSome additional information must be
available:
Simplest and most useful model requires that each process
declare the maximum number of resources of each type that it may
need. The deadlock-avoidance algorithm dynamically examines the
resourceallocation state to ensure that there can never be a
circular-wait condition. Resource-allocation state is defined by
the number of available and allocated resources, and the maximum
demands of the processes.
8
Safe State When a process requests an available resource, system
must decide if immediate allocation leaves the system in a safe
state. System is in safe state if there exists a safe sequence of
all processes. Sequence is safe if for each Pi, the resources that
Pi can still request can be satisfied by currently available
resources + resources held by all the Pj, with j satisfies safety
criteria.
14
Example P1 Request (1,0,2) (Cont.) Check that Request Available
(that is, (1,0,2) (3,3,2) true. Allocation Need Available ABC ABC
ABC Pretending P0 0 1 0 743 230 This Request P1 3 0 2 020 Has P2 3
0 1 600 Been Fullled P3 2 1 1 011 P4 0 0 2 431 Executing safety
algorithm shows that sequence satisfies safety requirement. Can
request for (3,3,0) by P4 be granted? Can request for (0,2,0) by P0
be granted?
Practice Question
Answer the following questions using the bankers algorithm:
a. What is the content of the matrix Need? b. Is the system in a
safe state? c. If a request from process P1 arrives for (0,4,2,0),
can the request be granted immediately?
15
Practice Question
a. What is the content of the matrix Need? The values of Need
for processes P0 through P4 respectively are (0, 0, 0, 0), (0, 7,
5, 0), (1,0, 0, 2), (0, 0, 2, 0), and (0, 6, 4, 2). b. Is the
system in a safe state? Yes. With Available being equal to (1,5, 2,
0), either process P0 or P3 could run. Once process P3 runs, it
releases its resources which allow all other existing processes to
run. c. If a request from process P1 arrives for (0,4,2,0), can the
request be granted immediately? Yes it can. This results in the
value of Available being (1, 1, 0, 0).One ordering of processes
that can finish is P0, P2, P3, P1, and P4.
Deadlock Detection Allow system to enter deadlock state
Detection algorithm Recovery scheme Overhead: algorithm and
recovery
16
Single Instance of Each Resource Type Maintain wait-for graph
Nodes are processes. Pi Pj if Pi is waiting for Pj.
Periodically invoke an algorithm that searches for a cycle in
the graph. An algorithm to detect a cycle in a graph requires an
order of n2 operations, where n is the number of vertices in the
graph.
Resource-Allocation Graph and Wait-for Graph
Resource-Allocation Graph
Corresponding wait-for graph
17
Several Instances of a Resource Type Available: A vector of
length m indicates the number of available resources of each type.
Allocation: An n x m matrix defines the number of resources of each
type currently allocated to each process. Request: An n x m matrix
indicates the current request of each process. If Request [ij] = k,
then process Pi is requesting k more instances of resource type.
Rj.
Detection Algorithm1. Let Work and Finish be vectors of length m
and n, respectively Initialize:(a) Work = Available (b)For i = 1,2,
, n, if Allocationi 0, then Finish[i] = false;otherwise, Finish[i]
= true.
2. Find an index i such that both:(a)Finish[i] == false
(b)Requesti Work If no such i exists, go to step 4.
18
Detection Algorithm (Cont.)3.Work = Work + Allocationi Finish[i]
= true go to step 2. 4.If Finish[i] == false, for some i, 1 i n,
then the system is in deadlock state. Moreover, if Finish[i] ==
false, then Pi is deadlocked.Algorithm requires an order of O(m x
n2) operations to detect whether the system is in deadlocked
state.
Example of Detection Algorithm Five processes P0 through P4;
three resource types A (7 instances), B (2 instances), and C (6
instances). Snapshot at time T0: AllocationRequest Available ABC
ABC ABC P0 0 1 0 000 000 P1 2 0 0 202 P2 3 0 3 000 P3 2 1 1 100 P4
0 0 2 002 Sequence will result in Finish[i] = true for all i.
19
Example (Cont.) P2 requests an additional instance of type C.
Request ABC P0 0 0 0 P1 2 0 1 P2 0 0 1 P3 1 0 0 P4 0 0 2 State of
system? Can reclaim resources held by process P0, but insufficient
resources to fulfill other processes; requests. Deadlock exists,
consisting of processes P1, P2, P3, and P4.
Detection-Algorithm Usage When, and how often, to invoke depends
on: How often a deadlock is likely to occur? How many processes
will need to be rolled back? one for each disjoint cycle If
detection algorithm is invoked arbitrarily, there may be many
cycles in the resource graph and so we would not be able to tell
which of the many deadlocked processes caused the deadlock.
20
Recovery from Deadlock: Process Termination Terminate a process:
Abort all deadlocked processes. Abort one process at a time until
the deadlock cycle is eliminated. (overhead) In which order should
we choose to abort? Priority of the process. How long process has
computed, and how much longer to completion. Resources the process
has used. Resources process needs to complete. How many processes
will need to be terminated. Is process interactive or batch?
Recovery from Deadlock: Resource Preemption Selecting a victim
minimize cost. Rollback return to some safe state, restart process
for that state. Starvation same process may always be picked as
victim, include number of rollback in cost factor.
21
Memory ManagementGordon College Stephen Brinton
Memory Management Background Swapping Contiguous Allocation
Paging Segmentation Segmentation with Paging
1
Background Program must be brought into memory and placed within
a process for it to be run hardware needs: - speed differential
(cache) - separate memory spaces (base and limit register) Base
Register: 34000 Limit Register: 12000 Address being used by a
program must fall within this range or a trap (error) will
result.
HW: address protection with base and limit registers
2
Address Binding Input queue collection of processes on the disk
that are waiting to be brought into memory to run the program
Binding symbolic addresses in a source program are bound to
actually memory addresses.
Binding of Instructions and Data to MemoryAddress binding of