gordon uni_operating systems (slides)_2010
TRANSCRIPT
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