Operating Systems: A Modern Perspective, Chapter 1

Operating Systems: A Modern Perspective, Chapter 1

Introduction Operating Systems: A Modern Perspective, Chapter 1

Why Study Operating Systems?
Understand the model of operation Easier to see how to use the system Enables you to write efficient code 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 Operating Systems: A Modern Perspective, Chapter 1

Perspectives of the Computer
print open() start-printer cut malloc() read-disk send save fork() track-mouse Application Software Application Software Application Software System Software System Software System Software Hardware Hardware Hardware End User View (b) Application Programmer View (c) OS Programmer View Operating Systems: A Modern Perspective, Chapter 1

System Software Independent of individual applications, but common to all of them Examples C library functions A window system A database management system Resource management functions The OS Operating Systems: A Modern Perspective, Chapter 1

Using the System Software
Application Programmer Software API Command Line Interpreter Loader Window System Libraries Libraries Libraries System Software Compiler OS Database Management System Hardware Operating Systems: A Modern Perspective, Chapter 1

Application Software, System Software, and the OS
Human-Computer Interface Application Software API System Software (More Abstract Resources) OS Interface Trusted OS (Abstract Resources) Software-Hardware Interface Hardware Resources Operating Systems: A Modern Perspective, Chapter 1

The OS as Resource Manager
Process: An executing program Resource: Anything that is needed for a process to run Memory Space on a disk The CPU “An OS creates resource abstractions” “An OS manages resource sharing” Operating Systems: A Modern Perspective, Chapter 1

Resource Abstraction load(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); } write(char *block, int len, int device,int addr); fprintf(fileID, “%d”, datum); Operating Systems: A Modern Perspective, Chapter 1

Disk Abstractions Application Programmer OS Programmer int fprintf(…) { ... write(…) … } void write() { load(…); seek(…) out(…) } load(…); seek(…); out(…); (a) Direct Control (b) write() abstraction (c) fprintf() abstraction Operating Systems: A Modern Perspective, Chapter 1

Abstract Resources User Interface Application Abstract Resources (API) Middleware OS Resources (OS Interface) OS Hardware Resources Operating Systems: A Modern Perspective, Chapter 1

Abstract Machines Abstract Machines Idea Program Result Physical Machine Idea Program Result … … … Idea Program Result Operating Systems: A Modern Perspective, Chapter 1

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 Concurrency Operating Systems: A Modern Perspective, Chapter 1

The OS as a Conductor The OS coordinates the sharing and use of all the components in the computer Operating Systems: A Modern Perspective, Chapter 1

Multiprogramming Abstract Machine Pi Abstract Machine Pj Abstract Machine Pk … OS Resource Sharing Pi Memory Pk Memory … Pj Memory Time-multiplexed Physical Processor Space-multiplexed Physical Memory Operating Systems: A Modern Perspective, Chapter 1

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 Operating Systems: A Modern Perspective, Chapter 1

How Multiprogramming Works
Process 1 Process 2 Process 3 Time-multiplexed CPU Process 4 Space-multiplexed Memory Operating Systems: A Modern Perspective, Chapter 1

Speeding Up the Car Wash
Vacuum Inside Wash Dry (a) The Sequential Car Wash Vacuum Inside Wash Dry (b) The Parallel Car Wash Operating Systems: A Modern Perspective, Chapter 1

Multiprogramming Performance
Pi’s Total Execution Time, ti Time ti (a) Pi’s Use of Machine Resources P1 P2 … Pi … PN Time (a) All Processes’ Use of Machine Resources Using the processor I/O operation Operating Systems: A Modern Perspective, Chapter 1

OS Strategies Batch processing Timesharing Personal computer & workstations Process control & real-time Network Distributed Small computers Operating Systems: A Modern Perspective, Chapter 1

Batch Processing Job 3 Job 19 Input Spooler Output Spooler Input Spool Output Spool Operating Systems: A Modern Perspective, Chapter 1

Batch Processing(2) 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 Operating Systems: A Modern Perspective, Chapter 1

A Shell Script Batch File
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 Operating Systems: A Modern Perspective, Chapter 1

Timesharing Systems Abstract Machines Result Physical Machine Command Result Command … Result Command Operating Systems: A Modern Perspective, Chapter 1

Timesharing Systems(2)
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 Operating Systems: A Modern Perspective, Chapter 1

Personal Computers CPU sharing among one person’s processes Power of computing for personal tasks Graphics Multimedia Trend toward very small OS OS focus on resource abstraction Rapidly evolved to “personal multitasking” systems Operating Systems: A Modern Perspective, Chapter 1

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 Operating Systems: A Modern Perspective, Chapter 1

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 ??? Operating Systems: A Modern Perspective, Chapter 1

Distributed OS Wave of the future App App App App App App Distributed OS Multiple Computers connected by a Network Operating Systems: A Modern Perspective, Chapter 1

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 Evolving & leading to new class of Oses PalmOS, Pocket PC (WinCE), VxWorks, … Operating Systems: A Modern Perspective, Chapter 1

Evolution of Modern OS Timesharing Network OS Memory Mgmt PC & Wkstation Client-Server Model Scheduling Batch Protection Protocols System software Real-Time Human-Computer Interface Memory Mgmt Protection Scheduling Scheduling Files Devices Small Computer Network storage, Resource management Modern OS Operating Systems: A Modern Perspective, Chapter 1

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 Research OSes – still evolving … Small computer OSes – still evolving … Book provides Linux examples This course will use Windows NT as the main example Operating Systems: A Modern Perspective, Chapter 1

The Microsoft OS Family
Win32 API Win32 API Subset Win32 API SubSet Windows CE (Pocket PC) Windows 95/98/Me Windows NT/2000/XP Operating Systems: A Modern Perspective, Chapter 1

Microsoft Windows NT Heavily window-oriented Foundation behavior is windows-independent We will focus on the foundation Use only the “MS-DOS prompt” -- cmd.exe OS API NT Executive NT User Interface and Graphics NT Kernel Operating Systems: A Modern Perspective, Chapter 1

Windows NT (cont) OS API has text orientation (like UNIX) Object-oriented implementation Heavy use of threads Broad spectrum of synchronization tools Modern I/O system Operating Systems: A Modern Perspective, Chapter 1

VxWorks Organization Applications VxWorks Runtime System
VxWorks Configurable Core OS Extension Wind Microkernel Operating Systems: A Modern Perspective, Chapter 1

Windows CE Organization
Operating Systems: A Modern Perspective, Chapter 1

Using the Operating System
2 Using the Operating System Operating Systems: A Modern Perspective, Chapter 2

The Airplane Pilot’s Abstract Machine

Basic Abstractions Idea Program Result Idea Program Result … … Idea Program Result Operating Systems: A Modern Perspective, Chapter 2

Basic Abstractions(2) Idea Abstract Machine Program Result Physical Machine Idea Abstract Machine Program Result … … Idea Abstract Machine Program Result Operating Systems: A Modern Perspective, Chapter 2

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.” Operating Systems: A Modern Perspective, Chapter 2

Algorithms, Programs, and Processes
Idea Execution Engine Files Algorithm Stack Status Source Program Binary Program Data Other Resources Process Operating Systems: A Modern Perspective, Chapter 2

Classic Process OS implements {abstract machine} – one per task Multiprogramming enables N programs to be space-muxed in executable memory, and time-muxed 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 Operating Systems: A Modern Perspective, Chapter 2

Process Abstraction Data Process Program Stack Operating System Processor Hardware Executable Memory Operating Systems: A Modern Perspective, Chapter 2

Processes Sharing a Program
Files P1 P2 P3 P1 Files P2 Files P3 Shared Program Text Operating Systems: A Modern Perspective, Chapter 2

Multithreaded Accountant
Invoice First Accountant Invoice Purchase Orders Invoice Accountant & Clone Purchase Orders Second Accountant (a) Separate Processes (b) Double Threaded Process Operating Systems: A Modern Perspective, Chapter 2

Modern Process & Thread
Divide classic process: 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 stack Stack Data Thread Thread Stack Process … Program Stack Thread Operating System Operating Systems: A Modern Perspective, Chapter 2

A Process with Multiple Threads
Thread (Execution Engine) Stack Status Files Stack Status Data Stack Status Other Resources Binary Program Process Operating Systems: A Modern Perspective, Chapter 2

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) 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 Operating Systems: A Modern Perspective, Chapter 2

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 Operating Systems: A Modern Perspective, Chapter 2

Shared Address Space Classic processes sharing program  shared address space support Thread model simplifies the problem All threads in a process implicitly use that process’s address space , but no “unrelated threads” have access to the address space Now trivial for threads to share a program and data If you want sharing, encode your work as threads in a process If you do not want sharing, place threads in separate processes Operating Systems: A Modern Perspective, Chapter 2

Process & Address Space
Resources Data Resources Code Resources Stack Abstract Machine Environment Address Space Operating Systems: A Modern Perspective, Chapter 2

Creating a Process Here is the classic model for creating processes: FORK(label): Create another process in the same address space beginning execution at instruction label QUIT(): Terminate the process. JOIN(count): disableInterrupts(); count--; if(count > 0) QUIT(); enableInterrupts(); Operating Systems: A Modern Perspective, Chapter 2

Example procA() { while(TRUE) { <compute section A1>; update(x); <compute section A2>; retrieve(y); } procB() { while(TRUE) { retrieve(x); <compute section B1>; update(y); <compute section B2>; } x Process A Process B y Operating Systems: A Modern Perspective, Chapter 2

Example (cont) L0: count = 2; <compute section A1>; update(x); FORK(L2); <compute section A2>; L1: JOIN(count); retrieve(y); goto L0; L2: retrieve(x); <compute section B1>; update(y); FORK(L3); goto L1; L3: <compute section B2> QUIT(); Operating Systems: A Modern Perspective, Chapter 2

Example (cont) L0: count = 2; <compute section A1>; update(x); FORK(L2); <compute section A2>; L1: JOIN(count); retrieve(y); goto L0; L2: retrieve(x); <compute section B1>; update(y); FORK(L3); goto L1; L3: <compute section B2> QUIT(); L0: count = 2; <compute section A1>; update(x); FORK(L2); retrieve(y); <compute section B1> update(y>; FORK(L3) L1: JOIN(count); goto L0; L2: <compute section A2>; goto L1; L3: <compute section B2> QUIT(); Operating Systems: A Modern Perspective, Chapter 2

UNIX Processes Files Stack Segment Status Text Segment Data Segment Other Resources Process UNIX Kernel Operating Systems: A Modern Perspective, Chapter 2

UNIX Processes Each process has its own address space Subdivided into text, data, & stack segment a.out file describes the address space OS kernel creates descriptor to manage process Process identifier (PID): User handle for the process (descriptor) Try “ps” and “ps -aux” (read man page) Operating Systems: A Modern Perspective, Chapter 2

Creating/Destroying Processes
UNIX fork() creates a process Creates a new address space Copies text, data, & stack into new adress space Provides child with access to open files UNIX wait() allows a parent to wait for a child to terminate UNIX execa() allows a child to run a new program Operating Systems: A Modern Perspective, Chapter 2

Creating a UNIX Process
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(…); Operating Systems: A Modern Perspective, Chapter 2

Child Executes a Different Program
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 */ Operating Systems: A Modern Perspective, Chapter 2

Example: Parent #include <sys/wait.h> #define NULL 0 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()); Operating Systems: A Modern Perspective, Chapter 2

Example: Child 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()); } Operating Systems: A Modern Perspective, Chapter 2

Threads -- The NT Model Thread (Execution Engine) Stack Status Files Stack Status Data Stack Status Other Resources Binary Program Process Operating Systems: A Modern Perspective, Chapter 2

Windows NT Process #include <cthreads.h> ... 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, …); } Operating Systems: A Modern Perspective, Chapter 2

NT Threads #include <cthreads.h> ... 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 */ Operating Systems: A Modern Perspective, Chapter 2

_beginthreadex() Single copy of certain variables in a process Need a copy per thread unsigned long _beginthreadex( void *security, unsigned stack_size, unsigned ( __stdcall *start_address )( void * ), void *arglist, unsigned initflag, unsigned *thrdaddr ); Operating Systems: A Modern Perspective, Chapter 2

Resources Anything that a process requests from an OS Available  allocated Not available  process is blocked 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 … Operating Systems: A Modern Perspective, Chapter 2

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 Operating Systems: A Modern Perspective, Chapter 2

The File Abstraction Data File Process Program Stack Operating System File Descriptor Processor Storage Device Hardware Executable Memory Operating Systems: A Modern Perspective, Chapter 2

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 Specifies file name to be used close Release file descriptor read Input a block of information write Output a block of information lseek Position file for read/write ioctl Device-specific operations Operating Systems: A Modern Perspective, Chapter 2

UNIX File Example #include <stdio.h> #include <fcntl.h> 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); } Operating Systems: A Modern Perspective, Chapter 2

Windows File Manipulation Program
#include <windows.h> #include <stdio.h> #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 Operating Systems: A Modern Perspective, Chapter 2

Windows File Manipulation Program(2)
// 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); } Operating Systems: A Modern Perspective, Chapter 2

// 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); } Operating Systems: A Modern Perspective, Chapter 2

// 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); Operating Systems: A Modern Perspective, Chapter 2

Shell Command Line Interpreter
Interactive User Application & System Software Shell Program OS System Call Interface OS Operating Systems: A Modern Perspective, Chapter 2

The Shell Strategy % grep first f3 read keyboard fork a process Shell Process Process to execute command f3 read file Operating Systems: A Modern Perspective, Chapter 2

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 Operating Systems: A Modern Perspective, Chapter 2

Initializing a UNIX Machine
Serial Port A login Serial Port B login Serial Port C login Serial Port Z login getty /etc/passwd Operating Systems: A Modern Perspective, Chapter 2

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 ... Operating Systems: A Modern Perspective, Chapter 2

Operating System Organization
3 Operating System Organization Operating Systems: A Modern Perspective, Chapter 3

Purpose of an OS Coordinate Use of the Abstractions Processes
Create the Abstractions Operating Systems: A Modern Perspective, Chapter 3

OS Requirements Provide resource abstractions Process abstraction of CPU/memory use Address space Thread abstraction of CPU within address space 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 Operating Systems: A Modern Perspective, Chapter 3

DOS -- Resource Abstraction Only
Program Program Libraries Program OS Services ROM Routines Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

OS Requirements (cont)
Provide resource abstractions Manage resource sharing Time/space-multiplexing Exclusive use of a resource Isolation Managed sharing Operating Systems: A Modern Perspective, Chapter 3

Abstraction & Sharing Program State Process Program State Process Libraries Program State Process OS Services Abstraction Manage sharing ROM Routines Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

OS Design Constraints Performance Protection and security Correctness Maintainability Commercial factors Standards and open systems Operating Systems: A Modern Perspective, Chapter 3

Performance The OS is an overhead function  should not use too much of machine’s resources Minimum functionality is to implement abstractions Additional function must be traded off against performance DOS: one process UNIX: low level file system Operating Systems: A Modern Perspective, Chapter 3

Protection & Security Multiprogramming  resource sharing Therefore, need software-controlled resource isolation Security policy: Sharing strategy chosen by computer’s owner Protection mechanism: Tool to implement a family of security policies Operating Systems: A Modern Perspective, Chapter 3

Correctness & Maintainability
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 Operating Systems: A Modern Perspective, Chapter 3

Device Management Device-Independent Part Device-Dependent Part Device-Dependent Part Device-Dependent Part … Device Device Device Operating Systems: A Modern Perspective, Chapter 3

Process, Thread, and Resource Management
Abstraction Process Abstraction Generic Resource Manager Multiprogramming Other … Primary Memory Abstract Resources Processor Operating Systems: A Modern Perspective, Chapter 3

Memory Management Isolation & Sharing Virtual Memory Block Allocation Process Manager Primary Memory Storage Devices Operating Systems: A Modern Perspective, Chapter 3

Exclusive Access to a Resource
Processor Process A Process B A’s Protected Object Supervisor Program Operating Systems: A Modern Perspective, Chapter 3

Processor Modes Mode bit: Supervisor or User mode Supervisor mode Can execute all machine instructions Can reference all memory locations User mode Can only execute a subset of instructions Can only reference a subset of memory locations Operating Systems: A Modern Perspective, Chapter 3

Kernels 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 Operating Systems: A Modern Perspective, Chapter 3

Supervisor and User Memory
Space User Process Supervisor Process Supervisor Space Operating Systems: A Modern Perspective, Chapter 3

Procedure Call and Message Passing Operating Systems
send(…, A, …); receive(…, B, …); receive(…A, …); … send(…, B, …); send/receive call(…); trap return; Operating Systems: A Modern Perspective, Chapter 3

System Call Using the trap Instruction
… fork(); Trap Table Kernel fork() { … trap N_SYS_FORK() } sys_fork() sys_fork() { /* system function */ … return; } Operating Systems: A Modern Perspective, Chapter 3

A Thread Performing a System Call
User Space Kernel Space Thread fork(); sys_fork() { } Operating Systems: A Modern Perspective, Chapter 3

Basic Operating System Organization
File Manager Process, Thread & Resource Manager Memory Manager Device Manager Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

The UNIX Architecture … … Interactive User Libraries Commands
Application Programs … OS System Call Interface Trap Table Device Driver Monolithic Kernel Module Process Management Memory Management File Management Device Mgmt Infrastructure Device Driver … Driver Interface Device Driver Operating Systems: A Modern Perspective, Chapter 3

Microkernel Organization
Process Process Libraries Process User Supervisor Server Server Server Device Drivers Microkernel Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

Windows NT Organization
Process Process T T Process T T T T Libraries T T T Process Management Memory Management File Management Device Mgmt Infrastructure Subsystem Subsystem Subsystem User Supervisor I/O Subsystem NT Executive NT Kernel Hardware Abstraction Layer Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

Monitoring the Kernel Process Process Process Libraries Subsystem
Task Manager T Process T T T T Libraries T T T pview pstat Subsystem Subsystem Subsystem User Supervisor I/O Subsystem NT Executive NT Kernel Hardware Abstraction Layer Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 3

Computer Organization
4 Computer Organization Operating Systems: A Modern Perspective, Chapter 4

Stored Program Computers and Electronic Devices
Pattern Jacquard Loom Variable Program Stored Program Device Fixed Electronic Device Operating Systems: A Modern Perspective, Chapter 4

Program Specification
Source int a, b, c, d; . . . a = b + c; d = a - 100; ; 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 Assembly Language Operating Systems: A Modern Perspective, Chapter 4

Machine Language 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 …1 …0 …0 …1 …0 …1 Machine Language Operating Systems: A Modern Perspective, Chapter 4

The von Neumann Architecture
Central Processing Unit (CPU) Arithmetical Logical Unit (ALU) Control Unit (CU) Address Bus Data Bus Device Primary Memory Unit (Executable Memory) Operating Systems: A Modern Perspective, Chapter 4

The ALU load R3,b load R4,c add R3,R4 store R3,a Right Operand Left Operand R1 R2 . . . Rn Functional Unit Status Registers Result To/from Primary Memory Operating Systems: A Modern Perspective, Chapter 4

Control Unit load R3,b load R4,c add R3,R4 store R3,a …1 …0 …0 …1 Fetch Unit Decode Unit Execute Unit PC IR Control Unit 3046 3050 3054 3058 3050 load R4, c Primary Memory Operating Systems: A Modern Perspective, Chapter 4

Control Unit Operation
Fetch phase: Instruction retrieved from memory Execute phase: ALU op, memory data reference, I/O, etc. PC = <machine start address>; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; // fetch phase }; Operating Systems: A Modern Perspective, Chapter 4

Primary Memory Unit 1234 1. Load MAR with address MAR 1 2 98765 3. Data will then appear in the MDR MDR Command read 2. Load Command with “read” 1234 98765 Read Op: n-1 Operating Systems: A Modern Perspective, Chapter 4

The Device-Controller-Software Relationship
Abstract I/O Machine Device manager Program to manage device controller Supervisor mode software Application Program Software in the CPU Device Controller Device Operating Systems: A Modern Perspective, Chapter 4

Device Controller Interface
busy done idle finished working (undefined) . . . busy done Error code . . . Command Status Data 0 Data 1 Logic Data n-1 Operating Systems: A Modern Perspective, Chapter 4

Performing a Write Operation
while(deviceNo.busy || deviceNo.done) <waiting>; deviceNo.data[0] = <value to write> deviceNo.command = WRITE; while(deviceNo.busy) <waiting>; deviceNo.done = TRUE; 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 Operating Systems: A Modern Perspective, Chapter 4

CPU-I/O Overlap … Ready Processes CPU Device … Ready Processes I/O Operation CPU Device … Ready Processes Uses CPU CPU Device Operating Systems: A Modern Perspective, Chapter 4

Determining When I/O is Complete
CPU 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 Operating Systems: A Modern Perspective, Chapter 4

Control Unit with Interrupt (Hardware)
PC = <machine start address>; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); if(InterruptRequest) { memory[0] = PC; PC = memory[1] }; memory[1] contains the address of the interrupt handler Operating Systems: A Modern Perspective, Chapter 4

Interrupt Handler (Software)
saveProcessorState(); for(i=0; i<NumberOfDevices; i++) if(device[i].done) goto deviceHandler(i); /* something wrong if we get to here … */ deviceHandler(int i) { finishOperation(); returnToScheduler(); } Operating Systems: A Modern Perspective, Chapter 4

A Race Condition saveProcessorState() { for(i=0; i<NumberOfRegisters; i++) memory[K+i] = R[i]; for(i=0; i<NumberOfStatusRegisters; i++) memory[K+NumberOfRegisters+i] = StatusRegister[i]; } PC = <machine start address>; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); if(InterruptRequest && InterruptEnabled) { disableInterupts(); memory[0] = PC; PC = memory[1] }; Operating Systems: A Modern Perspective, Chapter 4

Revisiting the trap Instruction (Hardware)
executeTrap(argument) { setMode(supervisor); switch(argument) { case 1: PC = memory[1001]; // Trap handler 1 case 2: PC = memory[1002]; // Trap handler 2 . . . case n: PC = memory[1000+n];// Trap handler n }; The trap instruction dispatches a trap handler routine atomically Trap handler performs desired processing “A trap is a software interrupt” Operating Systems: A Modern Perspective, Chapter 4

Direct Memory Access Primary Memory Primary Memory CPU CPU Controller Controller Device Device Operating Systems: A Modern Perspective, Chapter 4

Addressing Devices Primary Memory Primary Memory Memory Addresses Device 0 Memory Addresses Device 0 Device 1 Device 1 Device Addresses Device n-1 Device n-1 Operating Systems: A Modern Perspective, Chapter 4

Polling I/O … // Start the device While((busy == 1) || (done == 1)) wait(); // Device I/O complete done = 0; Software busy done … while((busy == 0) && (done == 1)) wait(); // Do the I/O operation busy = 1; Hardware Operating Systems: A Modern Perspective, Chapter 4

Fetch-Execute Cycle with an Interrupt
while (haltFlag not set during execution) { IR = memory[PC]; PC = PC + 1; execute(IR); if (InterruptRequest) { /* Interrupt the current process */ /* Save the current PC in address 0 */ memory[0] = PC; /* Branch indirect through address 1 */ PC = memory[1]; } Operating Systems: A Modern Perspective, Chapter 4

Detecting an Interrupt
CPU InterruptRequest flag Device Device Device Operating Systems: A Modern Perspective, Chapter 4

The Interrupt Handler Interrupt_Handler{ saveProcessorState(); for (i=0; i<Number_of_devices; i++) if (device[i].done == 1) goto device_handler(i); /* Something wrong if we get here */ } Operating Systems: A Modern Perspective, Chapter 4

Disabling Interrupts if(InterruptRequest && InterruptEnabled) { /* Interrupt current process */ disableInterrupts(); memory[0] = PC; PC = memory[1]; } Operating Systems: A Modern Perspective, Chapter 4

The Trap Instruction Operation
Mode S 1 Branch Table 2 trap 3 Trusted Code User Supervisor Operating Systems: A Modern Perspective, Chapter 4

Intel System Initialization
RAM Boot Prog ROM Loader Power Up Boot Device POST OS BIOS CMOS … Hardware Process Data Flow Operating Systems: A Modern Perspective, Chapter 4

Bootstrapping Bootstrap loader (“boot sector”) 1 Fetch Unit Decode Unit Execute Unit … PC IR BIOS loader 0x 0x Primary Memory Operating Systems: A Modern Perspective, Chapter 4

Bootstrapping Bootstrap loader (“boot sector”) 1 0x 2 BIOS loader 0x Fetch Unit Decode Unit Execute Unit … PC IR 0x Loader Primary Memory Operating Systems: A Modern Perspective, Chapter 4

Bootstrapping Bootstrap loader (“boot sector”) 1 0x 2 BIOS loader 0x Fetch Unit Decode Unit Execute Unit … PC IR 0x Loader 3 0x000A000 OS Primary Memory Operating Systems: A Modern Perspective, Chapter 4

Bootstrapping Bootstrap loader (“boot sector”) 1 0x 2 BIOS loader 0x 0x Fetch Unit Loader 3 PC 000A000 0x000A000 Decode Unit OS IR … Primary Memory Execute Unit 4. Initialize hardware 5. Create user environment 6. … Operating Systems: A Modern Perspective, Chapter 4

A Bootstrap Loader Program
FIXED_LOC: // Bootstrap loader entry point load R1, =0 load R2, =LENGTH_OF_TARGET // The next instruction is really more like // a procedure call than a machine instruction // It copies a block from FIXED_DISK_ADDRESS // to BUFFER_ADDRESS read BOOT_DISK, BUFFER_ADDRESS loop: load R3, [BUFFER_ADDRESS, R1] store R3, [FIXED_DEST, R1] incr R1 bleq R1, R2, loop br FIXED_DEST Operating Systems: A Modern Perspective, Chapter 4

A Pipelined Function Unit
Operand 1 Function Unit Result Operand 2 (a) Monolithic Unit Operand 1 Result Operand 2 (b) Pipelined Unit Operating Systems: A Modern Perspective, Chapter 4

A SIMD Machine ALU Control Unit (a) Conventional Architecture ALU Control Unit ALU ALU … ALU (b) SIMD Architecture Operating Systems: A Modern Perspective, Chapter 4

Device Management Operating Systems: A Modern Perspective, Chapter 5

Input/Output Devices Output Device Processor Input Device Operating Systems: A Modern Perspective, Chapter 5

The Device Driver Interface
… write(…); Device Interface Terminal Driver Printer Driver Disk Driver Terminal Controller Printer Controller Disk Controller Operating Systems: A Modern Perspective, Chapter 5

Device Management Organization
Application Process System Interface File Manager Device-Independent Device-Dependent Hardware Interface Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

System Call Interface Functions available to application programs Abstract all devices (and files) to a few interfaces Make interfaces as similar as possible Block vs character Sequential vs direct access Device driver implements functions (one entry point per API function) Operating Systems: A Modern Perspective, Chapter 5

Example: BSD UNIX Driver
open Prepare dev for operation close No longer using the device ioctl Character dev specific info read Character dev input op write Character dev output op strategy Block dev input/output ops select Character dev check for data stop Discontinue a stream output op Operating Systems: A Modern Perspective, Chapter 5

Overlapping the Operation of a Device and the CPU
. . . startRead(dev_I, “%d”, x); While(stillReading()) ; y = f(x) . . . read(dev_I, “%d”, x); y = f(x) Data on device Variable x Register Device dev_I Memory CPU Operating Systems: A Modern Perspective, Chapter 5

Overlapping CPU-Controller Operations in a Process
I/O Ctlr t1 t2 t3 t4 t5 t6 t7 t8 t9 Operating Systems: A Modern Perspective, Chapter 5

Overlapping Processing and I/O
I/O Ctlr t1 t2 t3 t4 Operating Systems: A Modern Perspective, Chapter 5

Polling I/O Read Operation
read(device, …); 1 Data System Interface read function 5 write function 2 3 4 Hardware Interface Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

Interrupt-driven I/O Operation
read(device, …); 9 1 8b Data System Interface Device Status Table 4 7 Device Handler read driver 2 write driver 6 3 8a Interrupt Handler Hardware Interface 5 Command Status Data Device Controller Operating Systems: A Modern Perspective, Chapter 5

Device Independent Function Call
Trap Table funci(…) dev_func_i(devID, …) { // Processing common to all devices … switch(devID) { case dev0: dev0_func_i(…); break; case dev1: dev1_func_i(…); case devM: devM_func_i(…); }; } Operating Systems: A Modern Perspective, Chapter 5

Driver-Kernel Interface
Drivers are distinct from main part of kernel Kernel makes calls on specific functions, drivers implement them Drivers use kernel functions for: Device allocation Resource (e.g., memory) allocation Scheduling etc. (varies from OS to OS) Operating Systems: A Modern Perspective, Chapter 5

Reconfigurable Device Drivers
System call interface open(){…} read(){…} Entry Points for Device j etc. Other Kernel services Driver for Device j Operating Systems: A Modern Perspective, Chapter 5

Handling Interrupts Device driver J Device interrupt handler J Device status table int read(…) { // Prepare for I/O save_state(J); out dev# // Done (no return) } void dev_handler(…) { get_state(J); //Cleanup after op signal(dev[j]); return_from_sys_call(); } J Interrupt Handler Device Controller Operating Systems: A Modern Perspective, Chapter 5

Handling Interrupts(2)
Device driver J Device interrupt handler J int read(…) { … out dev# // Return after interrupt wait(dev[J}); return_from_sys_call(); } void dev_handler(…) { //Cleanup after op signal(dev[j]); } Interrupt Handler Device Controller Operating Systems: A Modern Perspective, Chapter 5

The Pure Cycle Water Company
Customer Office Water Company Returning the Empties Water Producer Water Consumers Delivering Water Operating Systems: A Modern Perspective, Chapter 5

Hardware Buffering Process Process Process Controller Controller Controller Data A B A B Device Device Device Process reads bi-1 Controller reads bi Process reads bi Controller reads bi+1 Unbuffered Operating Systems: A Modern Perspective, Chapter 5

Double Buffering in the Driver
Process Process A B A B Driver Controller Controller A B A B Hardware Device Device Operating Systems: A Modern Perspective, Chapter 5

Circular Buffering To data consumer Buffer i Buffer j From data producer Operating Systems: A Modern Perspective, Chapter 5

A Generic Communications Device
Bus Generic Controller Communications Controller Local Device Cabling connecting the controller to the device Device Printer Modem Network Operating Systems: A Modern Perspective, Chapter 5

Rotating Media Cylinder (set of tracks) Track (Cylinder) Sector (a) Multi-surface Disk (b) Disk Surface (b) Cylinders Operating Systems: A Modern Perspective, Chapter 5

Storage Device Device Driver API Driver Get disk description Set SCSI parms read/write ops Interrupt hander SCSI API commands bits per byte etc. Controller (SCSI) Magnetic Disk Operating Systems: A Modern Perspective, Chapter 5

Compute vs I/O Bound Compute-bound Time I/O-bound Operating Systems: A Modern Perspective, Chapter 5

Disk Optimizations Transfer Time: Time to copy bits from disk surface to memory Disk latency time: Rotational delay waiting for proper sector to rotate under R/W head Disk seek time: Delay while R/W head moves to the destination track/cylinder Access Time = seek + latency + transfer Operating Systems: A Modern Perspective, Chapter 5

Optimizing Seek Time Multiprogramming on I/O-bound programs => set of processes waiting for disk Seek time dominates access time => minimize seek time across the set Tracks 0:99; Head at track 75, requests for 23, 87, 36, 93, 66 FCFS: = 251 steps Operating Systems: A Modern Perspective, Chapter 5

Optimizing Seek Time (cont)
Requests = 23, 87, 36, 93, 66 SSTF: (75), 66, 87, 93, 36, 23 = 107 steps Scan: (75), 87, 93, 99, 66, 36, 23 = 100 steps Look: (75), 87, 93, 66, 36, 23 = 87 steps Operating Systems: A Modern Perspective, Chapter 5

Optimizing Seek Time (cont)
Requests = 23, 87, 36, 93, 66 Circular Scan: (75), 87, 93, 99, 23, 36, 66 home = 90 + home Circular Look: (75), 87, 93, 23, 36, 66 home = 84 + home Operating Systems: A Modern Perspective, Chapter 5

Serial Port CPU Memory Serial Device Printer Terminal Modem Mouse etc. Operating Systems: A Modern Perspective, Chapter 5

Serial Port Device Driver API Device Driver Set UART parms read/write ops Interrupt hander Software on the CPU Bus Interface UART API parity bits per byte etc. Serial Device (UART) RS-232 Interface 9-pin connector 4-wires bit transmit/receive ... Operating Systems: A Modern Perspective, Chapter 5

Adding a Modem Switched Telephone Network Dialing & connecting
CPU Dialing & connecting Convert analog voice to/from digital Convert bytes to/from bit streams Transmit/receive protocol Memory Serial Device Modem Phone Switched Telephone Network Operating Systems: A Modern Perspective, Chapter 5

Serial Communication Device Driver Set UART parms read/write ops Interrupt hander Driver-Modem Protocol Dialing & connecting Convert analog voice to/from digital Convert bytes to/from bit streams Transmit/receive protocol Serial Device RS-232 Modem Operating Systems: A Modern Perspective, Chapter 5

Exploiting the Phone Network
Logical Communication CPU CPU Memory Comm Device Comm Device Memory Modem Modem Phone Phone Switched Telephone Network Operating Systems: A Modern Perspective, Chapter 5

Data Networks Technology focus includes protocols and software
(more on this later … Chapter 15 and beyond ...) Logical Communication CPU CPU Memory Network Device Network Device Memory Data Network Operating Systems: A Modern Perspective, Chapter 5

MS Disk Description Operating Systems: A Modern Perspective, Chapter 5

NT Driver Organization

NT Device Drivers API model is the same as for a file Extend device management by adding modules to the stream Device driver is invoked via an Interrupt Request Packet (IRP) IRP can come from another stream module IRP can come from the OS Driver must respond to minimum set of IRPs See Part I of notes Operating Systems: A Modern Perspective, Chapter 5

Implementing Processes, Threads, and Resources Operating Systems: A Modern Perspective, Chapter 6

Implementing the Process Abstraction
Pi Address Space Pi CPU Pi Executable Memory Pj Address Space Pj CPU Pj Executable Memory Pk Address Space … Pk CPU Pk Executable Memory OS interface OS Address Space CPU ALU Machine Executable Memory Control Unit … Operating Systems: A Modern Perspective, Chapter 6

External View of the Process Manager
Application Program Device Mgr Process Mgr Memory Mgr File Mgr Windows CreateThread() CreateProcess() CloseHandle() WaitForSingleObject() fork() wait() exec() Device Mgr Process Mgr Memory Mgr File Mgr UNIX Hardware Operating Systems: A Modern Perspective, Chapter 6

Process Manager Responsibilities
Define & implement the essential characteristics of a process and thread Algorithms to define the behavior Data structures to preserve the state of the execution Define what “things” threads in the process can reference – the address space (most of the “things” are memory locations) Manage the resources used by the processes/threads Tools to create/destroy/manipulate processes & threads Tools to time-multiplex the CPU – Scheduling the (Chapter 7) Tools to allow threads to synchronization the operation with one another (Chapters 8-9) Mechanisms to handle deadlock (Chapter 10) Mechanisms to handle protection (Chapter 14) Operating Systems: A Modern Perspective, Chapter 6

Modern Processes and Threads
Thrdj in Pi Thrdk in Pi … Pi CPU … … OS interface … Operating Systems: A Modern Perspective, Chapter 6

Processes &Threads Stack State Map State Stack Map Address Space Program Static data Resources Operating Systems: A Modern Perspective, Chapter 6

The Address Space Executable Memory Address Space Address Binding Process Files Other objects Operating Systems: A Modern Perspective, Chapter 6

Building the Address Space
Some parts are built into the environment Files System services Some parts are imported at runtime Mailboxes Network connections Memory addresses are created at compile (and run) time Operating Systems: A Modern Perspective, Chapter 6

Tracing the Hardware Process
Machine is Powered up Bootstap Process Manager Interrupt Handler P1 P,2 Pn Loader Load the kernel Initialization Execute a thread … Schedule Hardware process progress Service an interrupt Operating Systems: A Modern Perspective, Chapter 6

The Abstract Machine Interface
Application Program Abstract Machine Instructions Trap Instruction Supervisor Mode Instructions fork() create() open() OS User Mode Instructions User Mode Instructions Operating Systems: A Modern Perspective, Chapter 6

Context Switching Executable Memory Initialization 1 Process Manager 9 6 4 2 8 3 5 7 Interrupt Interrupt Handler P1 P2 Pn Operating Systems: A Modern Perspective, Chapter 6

Process Descriptors OS creates/manages process abstraction Descriptor is data structure for each process Register values Logical state Type & location of resources it holds List of resources it needs Security keys etc. (see Table 6.1 and the source code of your favorite OS) Operating Systems: A Modern Perspective, Chapter 6

Windows NT Process Descriptor
EPROCESS … void *UniqueProcessId; NT Executive KPROCESS … uint32 KernelTime; uint32 UserTime; Byte state; NT Kernel Operating Systems: A Modern Perspective, Chapter 6

Windows NT Process Descriptor (2)
Kernel process object including: Pointer to the page directory Kernel & user time Process base priority Process state List of the Kernel thread descriptors that are using this process Operating Systems: A Modern Perspective, Chapter 6

Windows NT Process Descriptor (3)
Parent identification Exit status Creation and termination times. Memory status Security information executable image Process priority class used by the thread scheduler. A list of handles used by this process A pointer to Win32-specific information Operating Systems: A Modern Perspective, Chapter 6

Windows NT Thread Descriptor
EPROCESS KPROCESS ETHREAD KTHREAD NT Kernel NT Executive Operating Systems: A Modern Perspective, Chapter 6

Creating a Process in UNIX
pid = fork(); UNIX kernel Process Table … Process Descriptor Operating Systems: A Modern Perspective, Chapter 6

Creating a Process in NT
CreateProcess(…); Win32 Subsystem ntCreateProcess(…); … ntCreateThread(…); NT Executive Handle Table NT Kernel … Process Descriptor Operating Systems: A Modern Perspective, Chapter 6

Windows NT Handles Operating Systems: A Modern Perspective, Chapter 6

Simple State Diagram Request Done Running Request Schedule Start Allocate Blocked Ready Operating Systems: A Modern Perspective, Chapter 6

UNIX State Transition Diagram
Request Wait by parent Done Running zombie Schedule Request Sleeping I/O Request Start Allocate Runnable I/O Complete Resume Traced or Stopped Uninterruptible Sleep Operating Systems: A Modern Perspective, Chapter 6

Windows NT Thread States
CreateThread Terminated Initialized Reinitialize Activate Dispatch Exit Wait Waiting Ready Running Wait Complete Wait Complete Select Preempt Transition Dispatch Standby Operating Systems: A Modern Perspective, Chapter 6

Resources Resource: Anything that a process can request, then be blocked because that thing is not available. R = {Rj | 0  j < m} = resource types C = {cj  0 |  RjR (0  j < m)} = units of Rj available Reusable resource: After a unit of the resource has been allocated, it must ultimately be released back to the system. E.g., CPU, primary memory, disk space, … The maximum value for cj is the number of units of that resource Consumable resource: There is no need to release a resource after it has been acquired. E.g., a message, input data, … Notice that cj is unbounded. Operating Systems: A Modern Perspective, Chapter 6

Using the Model There is a resource manager, Mgr(Rj) for every Rj pi can only request ni  cj units of reusable Rj pi can request unbounded # of units of consumable Rj Process pi can request units of Rj if it is currently running request Mgr(Rj) can allocate units of Rj to pi allocate Mgr(Rj) Process Operating Systems: A Modern Perspective, Chapter 6

A Generic Resource Manager
Blocked Processes Policy Process request() Process release() Resource Pool Operating Systems: A Modern Perspective, Chapter 6

Process Hierarchies Parent-child relationship may be significant: parent controls children’s execution Request Done Running Yield Suspend Request Schedule Suspend Start Ready-Active Activate Ready-Suspended Allocate Allocate Suspend Blocked-Active Blocked-Suspended Activate Operating Systems: A Modern Perspective, Chapter 6

Process Manager Overview
Program Process Abstract Computing Environment Deadlock Process Description File Manager Protection Synchronization Device Manager Memory Manager Resource Manager Scheduler Devices Memory CPU Other H/W Operating Systems: A Modern Perspective, Chapter 6

UNIX Organization Process Libraries Process Process System Call Interface Deadlock Process Description File Manager Protection Synchronization Device Manager Memory Manager Resource Manager Scheduler Monolithic Kernel Devices Memory CPU Other H/W Operating Systems: A Modern Perspective, Chapter 6

Windows NT Organization
Process Process T T Process T T T T Libraries T T T Subsystem Subsystem Subsystem User I/O Subsystem NT Executive NT Kernel Hardware Abstraction Layer Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 6

Scheduling Operating Systems: A Modern Perspective, Chapter 7

Model of Process Execution
Preemption or voluntary yield New Process Ready List Scheduler CPU Done job job “Running” job “Ready” Resource Manager Allocate Request job job “Blocked” Resources Operating Systems: A Modern Perspective, Chapter 7

Scheduler as CPU Resource Manager
Ready List Scheduler Ready to run Release Dispatch Release Dispatch Release Process Dispatch Units of time for a time-multiplexed CPU Operating Systems: A Modern Perspective, Chapter 7

The Scheduler From Other States Process Descriptor Ready Process Enqueuer Ready List Context Switcher Dispatcher CPU Running Process Operating Systems: A Modern Perspective, Chapter 7

Process/Thread Context
Right Operand Status Registers Left Operand R1 R2 . . . Rn Functional Unit ALU Result PC IR Ctl Unit Operating Systems: A Modern Perspective, Chapter 7

Context Switching Old Thread Descriptor CPU New Thread Descriptor Operating Systems: A Modern Perspective, Chapter 7

Invoking the Scheduler
Need a mechanism to call the scheduler Voluntary call Process blocks itself Calls the scheduler Involuntary call External force (interrupt) blocks the process Operating Systems: A Modern Perspective, Chapter 7

Voluntary CPU Sharing yield(pi.pc, pj.pc) { memory[pi.pc] = PC; PC = memory[pj.pc]; } pi can be “automatically” determined from the processor status registers yield(*, pj.pc) { memory[pi.pc] = PC; PC = memory[pj.pc]; } Operating Systems: A Modern Perspective, Chapter 7

More on Yield pi and pj can resume one another’s execution yield(*, pj.pc); . . . yield(*, pi.pc); Suppose pj is the scheduler: // p_i yields to scheduler yield(*, pj.pc); // scheduler chooses pk yield(*, pk.pc); // pk yields to scheduler // scheduler chooses ... Operating Systems: A Modern Perspective, Chapter 7

Voluntary Sharing Every process periodically yields to the scheduler Relies on correct process behavior Malicious Accidental Need a mechanism to override running process Operating Systems: A Modern Perspective, Chapter 7

Involuntary CPU Sharing
Interval timer Device to produce a periodic interrupt Programmable period IntervalTimer() { InterruptCount--; if(InterruptCount <= 0) { InterruptRequest = TRUE; InterruptCount = K; } SetInterval(programmableValue) { K = programmableValue: InterruptCount = K; } Operating Systems: A Modern Perspective, Chapter 7

Involuntary CPU Sharing (cont)
Interval timer device handler Keeps an in-memory clock up-to-date (see Chap 4 lab exercise) Invokes the scheduler IntervalTimerHandler() { Time++; // update the clock TimeToSchedule--; if(TimeToSchedule <= 0) { <invoke scheduler>; TimeToSchedule = TimeSlice; } Operating Systems: A Modern Perspective, Chapter 7

Contemporary Scheduling
Involuntary CPU sharing – timer interrupts Time quantum determined by interval timer – usually fixed size for every process using the system Sometimes called the time slice length Operating Systems: A Modern Perspective, Chapter 7

Choosing a Process to Run
Ready Process Enqueue Ready List Dispatch Context Switch Process Descriptor CPU Running Process Mechanism never changes Strategy = policy the dispatcher uses to select a process from the ready list Different policies for different requirements Operating Systems: A Modern Perspective, Chapter 7

Policy Considerations
Policy can control/influence: CPU utilization Average time a process waits for service Average amount of time to complete a job Could strive for any of: Equitability Favor very short or long jobs Meet priority requirements Meet deadlines Operating Systems: A Modern Perspective, Chapter 7

Optimal Scheduling Suppose the scheduler knows each process pi’s service time, t(pi) -- or it can estimate each t(pi) : Policy can optimize on any criteria, e.g., CPU utilization Waiting time Deadline To find an optimal schedule: Have a finite, fixed # of pi Know t(pi) for each pi Enumerate all schedules, then choose the best Operating Systems: A Modern Perspective, Chapter 7

However ... The t(pi) are almost certainly just estimates General algorithm to choose optimal schedule is O(n2) Other processes may arrive while these processes are being serviced Usually, optimal schedule is only a theoretical benchmark – scheduling policies try to approximate an optimal schedule Operating Systems: A Modern Perspective, Chapter 7

Model of Process Execution
Preemption or voluntary yield New Process Ready List Scheduler CPU Done job job “Running” job “Ready” Resource Manager Allocate Request job job “Blocked” Resources Operating Systems: A Modern Perspective, Chapter 7

Talking About Scheduling ...
Let P = {pi | 0  i < n} = set of processes Let S(pi)  {running, ready, blocked} Let t(pi) = Time process needs to be in running state (the service time) Let W(pi) = Time pi is in ready state before first transition to running (wait time) Let TTRnd(pi) = Time from pi first enter ready to last exit ready (turnaround time) Batch Throughput rate = inverse of avg TTRnd Timesharing response time = W(pi) Operating Systems: A Modern Perspective, Chapter 7

Simplified Model Preemption or voluntary yield New Process Ready List Scheduler CPU Done job job “Running” job “Ready” Resource Manager Allocate Request job job “Blocked” Resources Simplified, but still provide analysis result Easy to analyze performance No issue of voluntary/involuntary sharing Operating Systems: A Modern Perspective, Chapter 7

Estimating CPU Utilization
New Process Ready List Scheduler CPU Done Let l = the average rate at which processes are placed in the Ready List, arrival rate Let m = the average service rate  1/ m = the average t(pi) l pi per second System Each pi uses 1/ m units of the CPU Operating Systems: A Modern Perspective, Chapter 7

Estimating CPU Utilization
New Process Ready List Scheduler CPU Done Let l = the average rate at which processes are placed in the Ready List, arrival rate Let m = the average service rate  1/ m = the average t(pi) Let r = the fraction of the time that the CPU is expected to be busy r = # pi that arrive per unit time * avg time each spends on CPU r = l * 1/ m = l/m Notice must have l < m (i.e., r < 1) What if r approaches 1? Operating Systems: A Modern Perspective, Chapter 7

Nonpreemptive Schedulers
Blocked or preempted processes New Process Ready List Scheduler CPU Done Try to use the simplified scheduling model Only consider running and ready states Ignores time in blocked state: “New process created when it enters ready state” “Process is destroyed when it enters blocked state” Really just looking at “small phases” of a process Operating Systems: A Modern Perspective, Chapter 7

First-Come-First-Served
i t(pi) 350 p0 TTRnd(p0) = t(p0) = 350 W(p0) = 0 Operating Systems: A Modern Perspective, Chapter 7

i t(pi) 350 475 p0 p1 TTRnd(p0) = t(p0) = 350 TTRnd(p1) = (t(p1) +TTRnd(p0)) = = 475 W(p0) = 0 W(p1) = TTRnd(p0) = 350 Operating Systems: A Modern Perspective, Chapter 7

i t(pi) 475 950 p0 p1 p2 TTRnd(p0) = t(p0) = 350 TTRnd(p1) = (t(p1) +TTRnd(p0)) = = 475 TTRnd(p2) = (t(p2) +TTRnd(p1)) = = 950 W(p0) = 0 W(p1) = TTRnd(p0) = 350 W(p2) = TTRnd(p1) = 475 Operating Systems: A Modern Perspective, Chapter 7

i t(pi) 950 1200 p0 p1 p2 p3 TTRnd(p0) = t(p0) = 350 TTRnd(p1) = (t(p1) +TTRnd(p0)) = = 475 TTRnd(p2) = (t(p2) +TTRnd(p1)) = = 950 TTRnd(p3) = (t(p3) +TTRnd(p2)) = = 1200 W(p0) = 0 W(p1) = TTRnd(p0) = 350 W(p2) = TTRnd(p1) = 475 W(p3) = TTRnd(p2) = 950 Operating Systems: A Modern Perspective, Chapter 7

i t(pi) 1200 1275 p0 p1 p2 p3 p4 TTRnd(p0) = t(p0) = 350 TTRnd(p1) = (t(p1) +TTRnd(p0)) = = 475 TTRnd(p2) = (t(p2) +TTRnd(p1)) = = 950 TTRnd(p3) = (t(p3) +TTRnd(p2)) = = 1200 TTRnd(p4) = (t(p4) +TTRnd(p3)) = = 1275 W(p0) = 0 W(p1) = TTRnd(p0) = 350 W(p2) = TTRnd(p1) = 475 W(p3) = TTRnd(p2) = 950 W(p4) = TTRnd(p3) = 1200 Operating Systems: A Modern Perspective, Chapter 7

FCFS Average Wait Time i t(pi) Easy to implement Ignores service time, etc Not a great performer 350 475 900 1200 1275 p0 p1 p2 p3 p4 TTRnd(p0) = t(p0) = 350 TTRnd(p1) = (t(p1) +TTRnd(p0)) = = 475 TTRnd(p2) = (t(p2) +TTRnd(p1)) = = 950 TTRnd(p3) = (t(p3) +TTRnd(p2)) = = 1200 TTRnd(p4) = (t(p4) +TTRnd(p3)) = = 1275 W(p0) = 0 W(p1) = TTRnd(p0) = 350 W(p2) = TTRnd(p1) = 475 W(p3) = TTRnd(p2) = 950 W(p4) = TTRnd(p3) = 1200 Wavg = ( )/5 = 2974/5 = 595 Operating Systems: A Modern Perspective, Chapter 7

Predicting Wait Time in FCFS
In FCFS, when a process arrives, all in ready list will be processed before this job Let m be the service rate Let L be the ready list length Wavg(p) = L*1/m + 0.5* 1/m = L/m+1/(2m) Compare predicted wait with actual in earlier examples Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) 75 p4 TTRnd(p4) = t(p4) = 75 W(p4) = 0 Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) 75 200 p4 p1 TTRnd(p1) = t(p1)+t(p4) = = 200 TTRnd(p4) = t(p4) = 75 W(p1) = 75 W(p4) = 0 Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) 75 200 450 p4 p1 p3 TTRnd(p1) = t(p1)+t(p4) = = 200 TTRnd(p3) = t(p3)+t(p1)+t(p4) = = 450 TTRnd(p4) = t(p4) = 75 W(p1) = 75 W(p3) = 200 W(p4) = 0 Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) 75 200 450 800 p4 p1 p3 p0 TTRnd(p0) = t(p0)+t(p3)+t(p1)+t(p4) = = 800 TTRnd(p1) = t(p1)+t(p4) = = 200 TTRnd(p3) = t(p3)+t(p1)+t(p4) = = 450 TTRnd(p4) = t(p4) = 75 W(p0) = 450 W(p1) = 75 W(p3) = 200 W(p4) = 0 Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) 75 200 450 800 1275 p4 p1 p3 p0 p2 TTRnd(p0) = t(p0)+t(p3)+t(p1)+t(p4) = = 800 TTRnd(p1) = t(p1)+t(p4) = = 200 TTRnd(p2) = t(p2)+t(p0)+t(p3)+t(p1)+t(p4) = = 1275 TTRnd(p3) = t(p3)+t(p1)+t(p4) = = 450 TTRnd(p4) = t(p4) = 75 W(p0) = 450 W(p1) = 75 W(p2) = 800 W(p3) = 200 W(p4) = 0 Operating Systems: A Modern Perspective, Chapter 7

Shortest Job Next i t(pi) Minimizes wait time May starve large jobs Must know service times 75 200 450 800 1275 p4 p1 p3 p0 p2 TTRnd(p0) = t(p0)+t(p3)+t(p1)+t(p4) = = 800 TTRnd(p1) = t(p1)+t(p4) = = 200 TTRnd(p2) = t(p2)+t(p0)+t(p3)+t(p1)+t(p4) = = 1275 TTRnd(p3) = t(p3)+t(p1)+t(p4) = = 450 TTRnd(p4) = t(p4) = 75 W(p0) = 450 W(p1) = 75 W(p2) = 800 W(p3) = 200 W(p4) = 0 Wavg = ( )/5 = 1525/5 = 305 Operating Systems: A Modern Perspective, Chapter 7

Priority Scheduling i t(pi) Pri Reflects importance of external use May cause starvation Can address starvation with aging 250 375 850 925 1275 p3 p1 p2 p4 p0 TTRnd(p0) = t(p0)+t(p4)+t(p2)+t(p1) )+t(p3) = = 1275 TTRnd(p1) = t(p1)+t(p3) = = 375 TTRnd(p2) = t(p2)+t(p1)+t(p3) = = 850 TTRnd(p3) = t(p3) = 250 TTRnd(p4) = t(p4)+ t(p2)+ t(p1)+t(p3) = = 925 W(p0) = 925 W(p1) = 250 W(p2) = 375 W(p3) = 0 W(p4) = 850 Wavg = ( )/5 = 2400/5 = 480 Operating Systems: A Modern Perspective, Chapter 7

Deadline Scheduling i t(pi) Deadline (none) Allocates service by deadline May not be feasible 200 550 575 1050 1275 p1 p4 p0 p2 p3 p4 p1 p0 p2 p3 p4 p0 p1 p2 p3 Operating Systems: A Modern Perspective, Chapter 7

Preemptive Schedulers
Preemption or voluntary yield New Process Ready List Scheduler CPU Done Highest priority process is guaranteed to be running at all times Or at least at the beginning of a time slice Dominant form of contemporary scheduling But complex to build & analyze Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 50 p0 W(p0) = 0 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 p0 p1 W(p0) = 0 W(p1) = 50 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 p0 p1 p2 W(p0) = 0 W(p1) = 50 W(p2) = 100 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 p0 p1 p2 p3 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 p0 p1 p2 p3 p4 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 p0 p1 p2 p3 p4 p0 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 400 475 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 400 475 550 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 TTRnd(p1) = 550 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 400 475 550 650 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 p2 p3 650 750 850 950 p0 p2 p3 p0 p2 p3 TTRnd(p1) = 550 TTRnd(p3) = 950 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 400 475 550 650 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 p2 p3 650 750 850 950 1050 p0 p2 p3 p0 p2 p3 p0 p2 p0 TTRnd(p0) = 1100 TTRnd(p1) = 550 TTRnd(p3) = 950 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) i t(pi) 100 200 300 400 475 550 650 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 p2 p3 650 750 850 950 1050 1150 1250 1275 p0 p2 p3 p0 p2 p3 p0 p2 p0 p2 p2 p2 p2 TTRnd(p0) = 1100 TTRnd(p1) = 550 TTRnd(p2) = 1275 TTRnd(p3) = 950 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 Operating Systems: A Modern Perspective, Chapter 7

Round Robin (TQ=50) Equitable Most widely-used Fits naturally with interval timer i t(pi) 100 200 300 400 475 550 650 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 p2 p3 650 750 850 950 1050 1150 1250 1275 p0 p2 p3 p0 p2 p3 p0 p2 p0 p2 p2 p2 p2 TTRnd(p0) = 1100 TTRnd(p1) = 550 TTRnd(p2) = 1275 TTRnd(p3) = 950 TTRnd(p4) = 475 W(p0) = 0 W(p1) = 50 W(p2) = 100 W(p3) = 150 W(p4) = 200 TTRnd_avg = ( )/5 = 4350/5 = 870 Wavg = ( )/5 = 500/5 = 100 Operating Systems: A Modern Perspective, Chapter 7

RR with Overhead=10 (TQ=50)
Overhead must be considered i t(pi) 120 240 360 480 540 575 635 670 790 p0 p1 p2 p3 p4 p0 p1 p2 p3 p4 p0 p1 p2 p3 790 910 1030 1150 1270 1390 1510 1535 p0 p2 p3 p0 p2 p3 p0 p2 p0 p2 p2 p2 p2 TTRnd(p0) = 1320 TTRnd(p1) = 660 TTRnd(p2) = 1535 TTRnd(p3) = 1140 TTRnd(p4) = 565 W(p0) = 0 W(p1) = 60 W(p2) = 120 W(p3) = 180 W(p4) = 240 TTRnd_avg = ( )/5 = 5220/5 = 1044 Wavg = ( )/5 = 600/5 = 120 Operating Systems: A Modern Perspective, Chapter 7

Multi-Level Queues Preemption or voluntary yield Ready List0 New Process Scheduler Ready List1 CPU Done Ready List2 All processes at level i run before any process at level j At a level, use another policy, e.g. RR Ready List3 Operating Systems: A Modern Perspective, Chapter 7

Contemporary Scheduling
Involuntary CPU sharing -- timer interrupts Time quantum determined by interval timer -- usually fixed for every process using the system Sometimes called the time slice length Priority-based process (job) selection Select the highest priority process Priority reflects policy With preemption Usually a variant of Multi-Level Queues Operating Systems: A Modern Perspective, Chapter 7

BSD 4.4 Scheduling Involuntary CPU Sharing Preemptive algorithms 32 Multi-Level Queues Queues 0-7 are reserved for system functions Queues 8-31 are for user space functions nice influences (but does not dictate) queue level Operating Systems: A Modern Perspective, Chapter 7

Windows NT/2K Scheduling
Involuntary CPU Sharing across threads Preemptive algorithms 32 Multi-Level Queues Highest 16 levels are “real-time” Next lower 15 are for system/user threads Range determined by process base priority Lowest level is for the idle thread Operating Systems: A Modern Perspective, Chapter 7

Bank Teller Simulation
Customers Arrivals … Tn Tellers at the Bank Model of Tellers at the Bank Operating Systems: A Modern Perspective, Chapter 7

Simulation Kernel Loop
simulated_time = 0; while (true) { event = select_next_event(); if (event->time > simulated_time) simulated_time = event->time; evaluate(event->function, …); } Operating Systems: A Modern Perspective, Chapter 7

Simulation Kernel Loop(2)
void runKernel(int quitTime) { Event *thisEvent; // Stop by running to elapsed time, or by causing quit execute if(quitTime <= 0) quitTime = ; simTime = 0; while(simTime < quitTime) { // Get the next event if(eventList == NIL) { // No more events to process break; } thisEvent = eventList; eventList = thisEvent->next; simTime = thisEvent->getTime(); // Set the time // Execute this event thisEvent->fire(); delete(thisEvent); }; } Operating Systems: A Modern Perspective, Chapter 7

8 Basic Synchronization Principles

Concurrency Value of concurrency – speed & economics
But few widely-accepted concurrent programming languages (Java is an exception) Few concurrent programming paradigm Each problem requires careful consideration There is no common model OS tools to support concurrency tend to be “low level”

Command Execution … (a) UNIX Shell (b) Windows Command Launch
Enter Loop Enter Loop Another Command? Another Command? Exit Loop Exit Loop No No Yes Yes CreateProcess()code fork()code … Execute Command Execute Command Execute Command Wait for Child to Terminate (a) UNIX Shell (b) Windows Command Launch

Synchronizing Multiple Threads with a Shared Variable
Initialize CreateThread(…) Wait runTime seconds Thread Work … TRUE TRUE TRUE runFlag? runFlag=FALSE FALSE FALSE FALSE Terminate Exit

Traffic Intersections

Critical Sections Code for p1 Code for p2 . . . . . .
shared double balance; Code for p Code for p2 balance = balance + amount; balance = balance - amount; balance+=amount balance-=amount balance

Critical Sections (2) Execution of p1 Execution of p2 …
load R1, balance load R2, amount Timer interrupt … load R1, balance load R2, amount sub R1, R2 store R1, balance Timer interrupt add R1, R2 store R1, balance …

Critical Sections (3) 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() [Chapter 2] Terminate processes with QUIT() to synchronize Create processes whenever critical section is complete See Figure 8.7 … something new …

Disabling Interrupts Interrupts could be disabled arbitrarily long
shared double balance; Code for p1 Code for p2 disableInterrupts(); disableInterrupts(); balance = balance + amount; balance = balance - amount; enableInterrupts(); enableInterrupts(); 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 Variable Code for p1 Code for p2
shared boolean lock = FALSE; shared double balance; Code for p1 Code for p2 /* Acquire the lock */ /* Acquire the lock */ while(lock) ; while(lock) ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE;

Busy Wait Condition Code for p1 Code for p2 p2 p1
shared boolean lock = FALSE; shared double balance; Code for p1 Code for p2 /* Acquire the lock */ /* Acquire the lock */ while(lock) ; while(lock) ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE; p1 p2 at while Blocked lock = TRUE lock = FALSE Interrupt

Unsafe “Solution” Worse yet … another race condition …
shared boolean lock = FALSE; shared double balance; Code for p1 Code for p2 /* Acquire the lock */ /* Acquire the lock */ while(lock) ; while(lock) ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE; Worse yet … another race condition … Is it possible to solve the problem?

Atomic Lock Manipulation
enter(lock) { exit(lock) { disableInterrupts(); disableInterrupts(); /* Loop until lock is TRUE */ lock = FALSE; while(lock) { enableInterrupts(); /* Let interrupts occur */ } enableInterrupts(); disableInterrupts(); } lock = TRUE; 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 …

Fig 8-9: Deadlocked Pirates

Deadlock (2) Code for p1 Code for p2 shared boolean lock1 = FALSE;
shared list L; Code for p1 Code for p2 /* Enter CS to delete elt */ /* Enter CS to update len */ enter(lock1); enter(lock2); <delete element>; <update length>; <intermediate computation>; <intermediate computation> /* Enter CS to update len */ /* Enter CS to add elt */ enter(lock2); enter(lock1); <update length>; <add element>; /* Exit both CS */ /* Exit both CS */ exit(lock1); exit(lock2); exit(lock2); exit(lock1);

Processing Two Components
shared boolean lock1 = FALSE; shared boolean lock2 = FALSE; shared list L; Code for p1 Code for p2 /* Enter CS to delete elt */ /* Enter CS to update len */ enter(lock1); enter(lock2); <delete element>; <update length>; /* Exit CS */ /* Exit CS */ exit(lock1); exit(lock2); <intermediate computation>; <intermediate computation> /* Enter CS to update len */ /* Enter CS to add elt */ enter(lock2); enter(lock1); <update length>; <add element>; exit(lock2); exit(lock1);

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 Example: List manipulator Add or delete an element from a list Adjust the list descriptor, e.g., length Too heavyweight – need something simpler

A Semaphore

Dijkstra Semaphore Invented in the 1960s
Conceptual OS mechanism, with no specific implementation defined (could be enter()/exit()) Basis of all contemporary OS synchronization mechanisms

Solution Constraints 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() { proc_1() { while(TRUE) { while(TRUE { <compute section>; <compute section>; <critical section>; <critical section>; } } } } <shared global declarations> <initial processing> fork(proc_0, 0); fork(proc_1, 0);

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

Dijkstra Semaphore Definition
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]

Solving the Canonical Problem
Proc_0() { proc_1() { while(TRUE) { while(TRUE { <compute section>; <compute section>; P(mutex); P(mutex); <critical section>; <critical section>; V(mutex); V(mutex); } } } } semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

Shared Account Balance Problem
Proc_0() { proc_1() { /* Enter the CS */ /* Enter the CS */ P(mutex); P(mutex); balance += amount; balance -= amount; V(mutex); V(mutex); } } semaphore mutex = 1; fork(proc_0, 0); fork(proc_1, 0);

Sharing Two Variables proc_A() { while(TRUE) {
<compute section A1>; update(x); /* Signal proc_B */ V(s1); <compute section A2>; /* Wait for proc_B */ P(s2); retrieve(y); } semaphore s1 = 0; semaphore s2 = 0; fork(proc_A, 0); fork(proc_B, 0); proc_B() { while(TRUE) { /* Wait for proc_A */ P(s1); retrieve(x); <compute section B1>; update(y); /* Signal proc_A */ V(s2); <compute section B2>; }

Device Controller Synchronization
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)

Bounded Buffer Problem
Empty Pool Producer Consumer Full Pool

Bounded Buffer Problem (2)
producer() { buf_type *next, *here; while(TRUE) { produce_item(next); /* Claim an empty */ P(empty); P(mutex); here = obtain(empty); V(mutex); copy_buffer(next, here); release(here, fullPool); /* Signal a full buffer */ V(full); } 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); consumer() { buf_type *next, *here; while(TRUE) { /* Claim full buffer */ P(mutex); P(full); here = obtain(full); V(mutex); copy_buffer(here, next); release(here, emptyPool); /* Signal an empty buffer */ V(empty); consume_item(next); }

Bounded Buffer Problem (3)
producer() { buf_type *next, *here; while(TRUE) { produce_item(next); /* Claim an empty */ P(empty); P(mutex); here = obtain(empty); V(mutex); copy_buffer(next, here); release(here, fullPool); /* Signal a full buffer */ V(full); } 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); consumer() { buf_type *next, *here; while(TRUE) { /* Claim full buffer */ P(full); P(mutex); here = obtain(full); V(mutex); copy_buffer(here, next); release(here, emptyPool); /* Signal an empty buffer */ V(empty); consume_item(next); }

Readers-Writers Problem

Readers-Writers Problem (2)
Shared Resource

Shared Resource

First Solution First reader competes with writers
while(TRUE) { <other computing>; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); readCount--; if(readCount == 0) V(writeBlock); } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { <other computing>; P(writeBlock); /* Critical section */ access(resource); V(writeBlock); } First reader competes with writers Last reader signals writers

First Solution (2) First reader competes with writers
while(TRUE) { <other computing>; P(mutex); readCount++; if(readCount == 1) P(writeBlock); V(mutex); /* Critical section */ access(resource); readCount--; if(readCount == 0) V(writeBlock); } resourceType *resource; int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { <other computing>; 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

Writer Precedence 4 3 2 1 reader() { while(TRUE) {
<other computing>; P(readBlock); P(mutex1); readCount++; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); access(resource); readCount--; if(readCount == 0) V(writeBlock); } int readCount = 0, writeCount = 0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { <other computing>; P(mutex2); writeCount++; if(writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access(resource); V(writeBlock); P(mutex2) writeCount--; if(writeCount == 0) V(readBlock); } 4 3 2 1

Writer Precedence (2) 4 3 2 1 reader() { while(TRUE) {
<other computing>; P(writePending); P(readBlock); P(mutex1); readCount++; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); V(writePending); access(resource); readCount--; if(readCount == 0) V(writeBlock); } int readCount = 0, writeCount = 0; semaphore mutex = 1, mutex2 = 1; semaphore readBlock = 1, writeBlock = 1, writePending = 1; fork(reader, 0); fork(writer, 0); writer() { while(TRUE) { <other computing>; P(mutex2); writeCount++; if(writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access(resource); V(writeBlock); P(mutex2) writeCount--; if(writeCount == 0) V(readBlock); } 4 3 2 1

The Sleepy Barber Barber can cut one person’s hair at a time
Other customers wait in a waiting room Entrance to Waiting Room (sliding door) Shop Exit Entrance to Barber’s Room (sliding door) Waiting Room

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); } semaphore mutex = 1, chair = N, waitingCustomer = 0; int emptyChairs = N; fork(customer, 0); fork(barber, 0); barber() { while(TRUE) { P(waitingCustomer); P(mutex); emptyChairs++; takeCustomer(); V(mutex); V(chair); }

Cigarette Smoker’s Problem
Three smokers (processes) Each wish to use tobacco, papers, & matches Only need the three resources periodically Must have all at once 3 processes sharing 3 resources Solvable, but difficult

Implementing Semaphores
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(); } value--; }; V(){ value++;

Implementing Semaphores: Test and Set Instruction
TS(m): [Reg_i = memory[m]; memory[m] = TRUE;] Data Register CC Register TRUE m Primary Memory FALSE R3 =0 Data Register CC (b) After Executing TS R3 … … m FALSE Primary Memory Before Executing TS

Using the TS Instruction
boolean s = FALSE; . . . while(TS(s)) ; <critical section> s = FALSE; semaphore s = 1; . . . P(s) ; <critical section> V(s);

Implementing the General Semaphore
struct semaphore { int value = <initial 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 V(struct semaphore s) { while(TS(s.mutex)) ; s.value++; if(s.value <= 0) ( while(!s.hold) ; s.hold = FALSE; } s.mutex = FALSE;

Active vs Passive Semaphores
A process can dominate the semaphore Performs V operation, but continues to execute Performs another P operation before releasing the CPU Called a passive implementation of V Active implementation calls scheduler as part of the V operation. Changes semantics of semaphore! Cause people to rethink solutions

High Level Synchronization and Interprocess Communication
9 High Level Synchronization and Interprocess Communication Operating Systems: A Modern Perspective, Chapter 9

Large Amount of Work to Do

Partition the Work Operating Systems: A Modern Perspective, Chapter 9

Define Dependencies 1A 1B 2 3A 3B Operating Systems: A Modern Perspective, Chapter 9

Assign Work to Threads Thread Thread 1A 1B 2 3A 3B Operating Systems: A Modern Perspective, Chapter 9

Synchronize Thread Execution
1B 2 Synchronization Mechanism 3A 3B Operating Systems: A Modern Perspective, Chapter 9

The Dining Philosophers
Quiz: Write a synchronization schema for the problem Operating Systems: A Modern Perspective, Chapter 9

First Try Solution philosopher(int i) { while(TRUE) { // Think // Eat P(fork[i]); P(fork[(i+1) mod 5]); eat(); V(fork[(i+1) mod 5]); V(fork[i]); } 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); Deadlock Operating Systems: A Modern Perspective, Chapter 9

One Answer to the Quiz philosopher(int i) { while(TRUE) { // Think // Eat j = i % 2; P(fork[(i+j) mod 5]); P(fork[(i+1-j) mod 5]); eat(); V(fork[(i+1-j) mod 5]); V(fork[[(i+j) 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); Operating Systems: A Modern Perspective, Chapter 9

Nesting Semaphore Operations
pr P Operation Order ps P Operation Order P(mutex1); P(mutex2); P(mutex2); P(mutex1); <access R1>; <access R1>; <access R2>; <access R2>; V(mutex2); V(mutex1); V(mutex1); V(mutex2); (a) (b) Operating Systems: A Modern Perspective, Chapter 9

Abstracting Semaphores
Relatively simple problems, such as the dining philosophers problem, can be very difficult to solve Look for abstractions to simplify solutions AND synchronization Events Monitors … there are others ... Operating Systems: A Modern Perspective, Chapter 9

AND Synchronization Given two resources, R1 and R2 Some processes access R1, some R2, some both in the same critical section Need to avoid deadlock due to ordering of P operations Psimultaneous(S1, …, Sn) Operating Systems: A Modern Perspective, Chapter 9

Simultaneous Semaphores Def
P_sim(semaphore S, int N) { L1: if ((S[0]>=1)&& … &&(S[N-1]>=1)) { for(i=0; i<N; i++) S[i]--; } else { Enqueue the calling thread in the queue for the first S[i] where S[i]<1; The calling thread is blocked while it is in the queue; // When the thread is removed from the queue Goto L1; } V_sim(semaphore S, int N) { for(i=0; i<N; i++) { S[i]++; Dequeue all threads in the queue for S[i]; All such threads are now ready to run (but may be blocked again in Psimultaneous); } else { } Operating Systems: A Modern Perspective, Chapter 9

Simultaneous Semaphore
int R_num = 0, S_num = 0; Queue R_wait, S_wait; Semaphore mutex = 1; P_sim(PID callingThread, semaphore R, semaphore S) { L1: P(mutex); if(R.val>0)&&(S.val>0)) { P(R); P(S); V(mutex); } else { if(R.val==0) { R_num++; enqueue(callingThread, R_wait); goto L1; S_num++; enqueue(CallingThread, S_wait); } V_sim(semaphore R, semaphore S) { P(mutex); V(R); V(S); if(R_num>0) { R_num--; dequeue(R_wait); // Release a thread } if(S_num>0) { S_num--; dequeue(S_wait); // Release a thread V(mutex); Operating Systems: A Modern Perspective, Chapter 9

Dining Philosophers Problem
philosopher(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); Operating Systems: A Modern Perspective, Chapter 9

Events 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 Operating Systems: A Modern Perspective, Chapter 9

Example class Event { … public: void signal(); void wait() int queue(); } shared Event topOfHour; . . . // Wait until the top of the hour before proceding topOfHour.wait(); // It’s the top of the hour ... 1 wait() 3 shared Event topOfHour; . . . while(TRUE) if(isTopOfHour()) while(topOfHour.queue() > 0) topOfHour.signal(); } Resume topOfHour 2 signal() Operating Systems: A Modern Perspective, Chapter 9

UNIX Signals A UNIX signal corresponds to an event It is raised by one process (or hardware) to call another process’s 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. Operating Systems: A Modern Perspective, Chapter 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 Operating Systems: A Modern Perspective, Chapter 9

More on Signals (cont) OS signal system call 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 Operating Systems: A Modern Perspective, Chapter 9

Signal Handling /* code for process p */ . . . signal(SIG#, myHndlr); /* ARBITRARY CODE */ void myHndlr(...) { /* ARBITRARY CODE */ } Operating Systems: A Modern Perspective, Chapter 9

Signal Handling /* code for process p */ . . . signal(SIG#, sig_hndlr); /* ARBITRARY CODE */ void sig_hndlr(...) { /* ARBITRARY CODE */ } An executing process, q Raise “SIG#” for “p” sig_hndlr runs in p’s address space q is blocked q resumes execution Operating Systems: A Modern Perspective, Chapter 9

Using UNIX Signals Pi’s Address Space Pi’s Execution Pj’s Execution program Pi’s Signal Handler signal hndlr data stack & heap Operating Systems: A Modern Perspective, Chapter 9

Toy Signal Handler #include <signal.h> 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”); } Operating Systems: A Modern Perspective, Chapter 9

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”); default: break; } return Operating Systems: A Modern Perspective, Chapter 9

NT Event Object int main(…) { … evntHandle[PART2] = CreateEvent(NULL, TRUE, FALSE, NULL); evntHandle[PART3] = CreateEvent(NULL, TRUE, FALSE, NULL); … CreateThread(…, threadY, …) …; // Create thread Y // Do part 1A SetEvent(evntHandle[PART2]); WaitForSingleObject(evntHandle[PART3]) ResetEvent(evntHandle[PART3]); // Do part 3A } Operating Systems: A Modern Perspective, Chapter 9

NT Event Object (cont) DWORD WINAPI threadY(LPVOID) { … // Do part 1B WaitForSingleObject(evntHandle[PART2]); ResetEvent(evntHandle[PART2]); // Do part 2 SetEvent(evntHandle[Part3]); // Do Part 3B … } Operating Systems: A Modern Perspective, Chapter 9

NT Events Thread Thread Thread WaitForSingleObject(mutexR, time); WaitForSingleObject(mutexR, time); WaitForSingleObject(mutexR, time); Operating Systems: A Modern Perspective, Chapter 9

NT Mutex Object int main(…) { // This is a controlling thread … // Open resource R // Create Mutex objects (signaled) mutexR = CreateMutex(NULL, FALSE, NULL); … CreateThread(…, workerThrd, …) …; } Operating Systems: A Modern Perspective, Chapter 9

NT Mutex Object (cont) DWORD WINAPI workerThrd(LPVOID) { … while(…) { // Perform work // Obtain mutex while(WaitForSingleObject(mutexR) != WAIT_OBJECT_0); // Access the resource R ReleaseMutex(mutexR;) } Operating Systems: A Modern Perspective, Chapter 9

NT Events Thread WaitForMultipleObjects(…, objHnd, …); Operating Systems: A Modern Perspective, Chapter 9

Waiting for Multiple Objects
#define N … … HANDLE objHnd[N]; for(i = 0; i < N; i++) { objHnd[I] = CreateThread(…); } WaitForMultipleObjects(N, objHnd, TRUE, INFINITE); Operating Systems: A Modern Perspective, Chapter 9

NT Events Thread CreateThread(…) WaitForSingleObject(foo, time); (Analogous to a P-operation) Set flag not signaled Signaled/not signaled flag Kernel object Thread terminates  become signaled (Analogous to a V-operation) Thread Object Operating Systems: A Modern Perspective, Chapter 9

NT Waitable Timers Thread SetWaitableTimer(…delta…) (Schedules an event occurrence) WaitForSingleObject(foo, time); (Analogous to a P-operation) Set flag not signaled Signaled/not signaled flag Kernel object Timer expires  become signaled (Analogous to a V-operation) Waitable timer Operating Systems: A Modern Perspective, Chapter 9

Monitors Specialized form of ADT Encapsulates implementation Public interface (types & functions) Only one process can be executing in the ADT at a time monitor anADT { semaphore mutex = 1; // Implicit . . . public: proc_i(…) { P(mutex); // Implicit <processing for proc_i>; V(mutex); // Implicit }; Operating Systems: A Modern Perspective, Chapter 9

Example: Shared Balance
monitor sharedBalance { double balance; public: credit(double amount) {balance += amount;}; debit(double amount) {balance -= amount;}; . . . }; Operating Systems: A Modern Perspective, Chapter 9

Example: Readers & Writers
monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startRead() { }; finishRead() { startWrite() { finishWrite() { reader(){ while(TRUE) { . . . startRead(); finishRead(); } fork(reader, 0); fork(reader, 0): fork(writer, 0); writer(){ while(TRUE) { . . . startWriter(); finishWriter(); } Operating Systems: A Modern Perspective, Chapter 9

monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startRead() { while(numberOfWriters != 0) ; numberOfReaders++; }; finishRead() { numberOfReaders-; startWrite() { numberOfWriters++; while( busy || (numberOfReaders > 0) ) ; busy = TRUE; }; finishWrite() { numberOfWriters--; busy = FALSE; Operating Systems: A Modern Perspective, Chapter 9

Deadlock can happen monitor readerWriter_1 { int numberOfReaders = 0; int numberOfWriters = 0; boolean busy = FALSE; public: startRead() { while(numberOfWriters != 0) ; numberOfReaders++; }; finishRead() { numberOfReaders--; startWrite() { numberOfWriters++; while( busy || (numberOfReaders > 0) ) ; busy = TRUE; }; finishWrite() { numberOfWriters--; busy = FALSE; Operating Systems: A Modern Perspective, Chapter 9

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 Condition Variable Operating Systems: A Modern Perspective, Chapter 9

Condition Variables 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 Operating Systems: A Modern Perspective, Chapter 9

Active vs Passive signal
Hoare semantics: same as active semaphore p0 executes signal while p1 is waiting  p0 yields the monitor to p1 The signal is only TRUE the instant it happens 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 Operating Systems: A Modern Perspective, Chapter 9

Hoare vs Mesa Semantics
Hoare semantics: . . . if(resourceNotAvailable()) resourceCondition.wait(); /* now available … continue … */ Mesa semantics: . . . while(resourceNotAvailable()) resourceCondition.wait(); /* now available … continue … */ Operating Systems: A Modern Perspective, Chapter 9

2nd Try at Readers & Writers
monitor readerWriter_2 { int numberOfReaders = 0; boolean busy = FALSE; condition okToRead, okToWrite; public: startRead() { if(busy || (okToWrite.queue()) okToRead.wait(); numberOfReaders++; okToRead.signal(); }; finishRead() { numberOfReaders--; if(numberOfReaders == 0) okToWrite.signal(); startWrite() { if((numberOfReaders != 0) || busy) okToWrite.wait(); busy = TRUE; }; finishWrite() { busy = FALSE; if(okToRead.queue()) okToRead.signal() else okToWrite.signal() Operating Systems: A Modern Perspective, Chapter 9

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 Operating Systems: A Modern Perspective, Chapter 9

Example: Synchronizing Traffic
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(); } Operating Systems: A Modern Perspective, Chapter 9

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; Operating Systems: A Modern Perspective, Chapter 9

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); } Operating Systems: A Modern Perspective, Chapter 9

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. See paper by Lampson & Redell Operating Systems: A Modern Perspective, Chapter 9

IPC Mechanisms Message OS IPC Mechanism Must bypass memory protection mechanism for local copies Must be able to use a network for remote copies Info copy Info to be shared Address Space for p0 Address Space for p1 Operating Systems: A Modern Perspective, Chapter 9

Refined IPC Mechanism Spontaneous changes to p1’s address space Avoid through the use of mailboxes Address Space for p0 Address Space for p1 Mailbox for p1 Info to be shared Info copy Message Message Message send(… p1, …); receive(…); OS Interface send function receive function Operating Systems: A Modern Perspective, Chapter 9

Refined IPC Mechanism OS manages the mailbox space More secure message system Address Space for p0 Address Space for p1 Info to be shared Info copy send(… p1, …); receive(…); OS Interface Mailbox for p1 Message Message send function Message receive function Operating Systems: A Modern Perspective, Chapter 9

Interprocess Communication (IPC)
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 Operating Systems: A Modern Perspective, Chapter 9

Message Protocols Sender transmits a set of bits to receiver 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 Operating Systems: A Modern Perspective, Chapter 9

Transmit Operations Asynchronous send: Delivers message to receiver’s 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 Operating Systems: A Modern Perspective, Chapter 9

Receive Operation Blocking receive: Return the first message in the mailbox If there is no message in mailbox, block the receiver until one arrives Nonblocking receive: If there is no message in mailbox, return with an indication to that effect Operating Systems: A Modern Perspective, Chapter 9

Synchronized IPC Code for p1 Code for p2 /* signal p2 */ syncSend(message1, p2); <waiting …>; /* wait for signal from p2 */ blockReceive(msgBuff, &from); /* wait for signal from p1 */ blockReceive(msgBuff, &from); <process message>; /* signal p1 */ syncSend(message2, p1); syncSend(…) blockReceive(…) blockReceive(…) syncSend(…) Operating Systems: A Modern Perspective, Chapter 9

Asynchronous IPC Code for p1 Code for p2 /* signal p2 */ asyncSend(message1, p2); <other processing>; /* wait for signal from p2 */ while(!nbReceive(&msg, &from)); /* test for signal from p1 */ if(nbReceive(&msg, &from)) { <process message>; asyncSend(message2, p1); }else< <other processing>; } nonblockReceive(…) asyncSend(…) nonblockReceive(…) nonblockReceive(…) asyncSend(…) nonblockReceive(…) Operating Systems: A Modern Perspective, Chapter 9

UNIX Pipes Address Space for p1 Info to be shared Info copy write(pipe[1], …); read(pipe[0]); System Call Interface pipe for p1 and p2 write function read function Operating Systems: A Modern Perspective, Chapter 9

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 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 Operating Systems: A Modern Perspective, Chapter 9

UNIX Pipes (cont) File handles are copied on fork … so are pipe handles int pipeID[2]; . . . pipe(pipeID); if(fork() == 0) { /* the child */ read(pipeID[0], childBuf, len); <process the message>; } else { /* the parent */ write(pipeID[1], msgToChild, len); } Operating Systems: A Modern Perspective, Chapter 9

UNIX Pipes (cont) 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 <sys/ioctl.h> . . . int pipeID[2]; pipe(pipeID); ioctl(pipeID[0], FIONBIO, &on); read(pipeID[0], buffer, len); if(errno != EWOULDBLOCK) { /* no data */ } else { /* have data */ Operating Systems: A Modern Perspective, Chapter 9

Source, Filter and Sink Processes

Information Flow Through UNIX Pipes
Address Space for p1 Info to be shared Info copy write(pipe[1], …); read(pipe[0]); System Call Interface pipe for p1 and p2 write function read function Operating Systems: A Modern Perspective, Chapter 9

Deadlock Operating Systems: A Modern Perspective, Chapter 10

Example Process 1 Process 2 Resource 1 Resource 2 Process holds the resource Process requests the resource Operating Systems: A Modern Perspective, Chapter 10

Three Deadlocked Processes
Resource 1 Resource 2 Resource 3 Process holds the resource Process requests the resource Operating Systems: A Modern Perspective, Chapter 10

A Model P = {p1, p2, …, pn} be a set of processes R = {R1, R2, …, Rm} be a set of resources cj = number of units of Rj in the system S = {S0, S1, …} be a set of states representing the assignment of Rj to pi State changes when processes take action This allows us to identify a deadlock situation in the operating system Operating Systems: A Modern Perspective, Chapter 10

State Transitions The system changes state because of the action of some process, pi There are three pertinent actions: Request (“ri”): request one or more units of a resource Allocation (“ai”): All outstanding requests from a process for a given resource are satisfied Deallocation (“di”): The process releases units of a resource xi Sj Sk Operating Systems: A Modern Perspective, Chapter 10

Properties of States Want to define deadlock in terms of patterns of transitions Define: pi is blocked in Sj if pi cannot cause a transition out of Sj Sj r3 a1 r1 p2 is blocked in Sj Operating Systems: A Modern Perspective, Chapter 10

Properties of States (cont)
If pi is blocked in Sj, and will also be blocked in every Sk reachable from Sj, then pi is deadlocked Sj is called a deadlock state Operating Systems: A Modern Perspective, Chapter 10

A Simple Process-Resource Model Instance
Process holds resource Process requests resource Operating Systems: A Modern Perspective, Chapter 10

Example One process, two units of one resource Can request one unit at a time d d r a r a S0 S1 S2 S3 S4 Operating Systems: A Modern Perspective, Chapter 10

Extension of Example d0 d0 r0 a0 r0 a0 S00 S10 S20 S30 S40 r1 r1 r1 r1 r1 d0 d0 r0 a0 r0 a0 S01 S11 S21 S31 S41 d1 d1 d1 d1 a1 a1 a1 a1 d0 r0 a0 r0 S02 S12 S22 S32 r1 r1 d0 r1 r1 r0 a0 r0 S03 S13 S23 S33 d1 d1 a1 a1 r0 S04 S14 Operating Systems: A Modern Perspective, Chapter 10

Figure 10‑10: A Model of a State with a Circular Wait
P Ri P holds R Pi P R P requests R Operating Systems: A Modern Perspective, Chapter 10

Dining Philosophers Revisited
philosopher(int i){ while (TRUE) { // Think // Eat P(fork[i]); /* Pick up left fork */ P(fork[(i+1) mod 5]); /* Pick up right fork */ eat(); V(fork[(i+1) mod 5]); V(fork[i]); } philosopher4(){ P(fork[0]); /* Pick up right fork */ P(fork[4]); /* Pick up left fork */ V(fork[4]); V(fork[0]); semaphore fork[5]; fork[0] = fork[1] = fork[2] = fork[3] = fork[4] = 1; fork(philosopher, 1, 0); fork(philosopher, 1, 1); fork(philosopher, 1, 2); fork(philosopher, 1, 3); fork(philosopher4, 0); Operating Systems: A Modern Perspective, Chapter 10

Addressing Deadlock Prevention: Design the system so that deadlock is impossible Avoidance: Construct a model of system states, then choose a strategy that will not allow the system to go to a deadlock state Detection & Recovery: Check for deadlock (periodically or sporadically), then recover Manual intervention: Have the operator reboot the machine if it seems too slow Operating Systems: A Modern Perspective, Chapter 10

Prevention Necessary conditions for deadlock Mutual exclusion Hold and wait Circular waiting No preemption Ensure that at least one of the necessary conditions is false at all times Mutual exclusion must hold at all times Operating Systems: A Modern Perspective, Chapter 10

Hold and Wait Need to be sure a process does not hold one resource while requesting another Approach 1: Force a process to request all resources it needs at one time Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs What does this say about state transition diagrams? Operating Systems: A Modern Perspective, Chapter 10

Circular Wait Have a situation in which there are K processes holding units of K resources R P Ri P holds R Pi P R P requests R Operating Systems: A Modern Perspective, Chapter 10

Circular Wait (cont) There is a cycle in the graph of processes and resources Choose a resource request strategy by which no cycle will be introduced Total order on all resources, then can only ask for Rj if Ri < Rj for all Ri the process is currently holding Operating Systems: A Modern Perspective, Chapter 10

Circular Wait (cont) There is a cycle in the graph of processes and resources Choose a resource request strategy by which no cycle will be introduced Total order on all resources, then can only ask for Rj if Ri < Rj for all Ri the process is currently holding This is how we noticed the easy solution for the dining philosophers Operating Systems: A Modern Perspective, Chapter 10

Allowing Preemption Allow a process to time-out on a blocked request -- withdrawing the request if it fails ru Si Sj wu dv ru Sk Operating Systems: A Modern Perspective, Chapter 10

Avoidance Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state Requires extra information, e.g., the maximum claim for each process Allows resource manager to see the worst case that could happen, then to allow transitions based on that knowledge Operating Systems: A Modern Perspective, Chapter 10

Safe vs Unsafe States Safe state: one in which the system can assure that any sequence of subsequent transitions leads back to the initial state Even if all exercise their maximum claim, there is an allocation strategy by which all claims can be met Unsafe state: one in which the system cannot guarantee that the system will transition back to the initial state Unsafe state can lead to a deadlock state if too many processes exercise their maximum claim at once Operating Systems: A Modern Perspective, Chapter 10

More on Safe & Unsafe States
Likely to be in a safe state Probability of being in unsafe state increases Normal Execution No Request Max Claim Yes Execute, then release Operating Systems: A Modern Perspective, Chapter 10

More on Safe & Unsafe States
I Disallow Safe States Unsafe States Deadlock States Operating Systems: A Modern Perspective, Chapter 10

Banker’s Algorithm Let maxc[i, j] be the maximum claim for Rj by pi Let alloc[i, j] be the number of units of Rj held by pi Can always compute avail[j] = cj - S0i< nalloc[i,j] Then number of available units of Rj Should be able to determine if the state is safe or not using this info Operating Systems: A Modern Perspective, Chapter 10

Banker’s Algorithm Copy the alloc[i,j] table to alloc’[i,j] Given C, maxc and alloc’, compute avail vector Find pi: maxc[i,j] - alloc’[i,j]  avail[j] for 0  j < m and 0  i < n. If no such pi exists, the state is unsafe If alloc’[i,j] is 0 for all i and j, the state is safe Set alloc’[i,j] to 0; deallocate all resources held by pi; go to Step 2 Operating Systems: A Modern Perspective, Chapter 10

Example Maximum Claim C = <8, 5, 9, 7> Process R0 R1 R2 R3 p p p p p Compute total allocated Determine available units avail = <8-7, 5-3, 9-7, 7-5> = <1, 2, 2, 2> Can anyone’s maxc be met? maxc[2,0]-alloc’[2,0] = 5-4 = 11 = avail[0] maxc[2,1]-alloc’[2,1] = 1-0 = 12 = avail[1] maxc[2,2]-alloc’[2,2] = 0-0 = 02 = avail[2] maxc[2,3]-alloc’[2,3] = 5-3 = 22 = avail[3] Allocated Resources Process R0 R1 R2 R3 p p p p p Sum P2 can exercise max claim avail[0] = avail[0]+alloc’[2,0] = 1+4 = 5 avail[1] = avail[1]+alloc’[2,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[2,2] = 2+0 = 2 avail[3] = avail[3]+alloc’[2,3] = 2+3 = 5 Operating Systems: A Modern Perspective, Chapter 10

Example Maximum Claim C = <8, 5, 9, 7> Process R0 R1 R2 R3 p p p p p Compute total allocated Determine available units avail = <8-7, 5-3, 9-7, 7-5> = <5, 2, 2, 5> Can anyone’s maxc be met? maxc[4,0]-alloc’[4,0] = 5-1 = 45 = avail[0] maxc[4,1]-alloc’[4,1] = 0-0 = 02 = avail[1] maxc[4,2]-alloc’[4,2] = 3-3 = 02 = avail[2] maxc[4,3]-alloc’[4,3] = 3-0 = 35 = avail[3] Allocated Resources Process R0 R1 R2 R3 p p p p p Sum P4 can exercise max claim avail[0] = avail[0]+alloc’[4,0] = 5+1 = 6 avail[1] = avail[1]+alloc’[4,1] = 2+0 = 2 avail[2] = avail[2]+alloc’[4,2] = 2+3 = 5 avail[3] = avail[3]+alloc’[4,3] = 5+0 = 5 Operating Systems: A Modern Perspective, Chapter 10

Example Maximum Claim C = <8, 5, 9, 7> Process R0 R1 R2 R3 p p p p p Compute total allocated Determine available units avail = <8-7, 5-3, 9-7, 7-5> = <6, 2, 5, 5> Can anyone’s maxc be met? (Yes, any of them can) Allocated Resources Process R0 R1 R2 R3 p p p p p Sum Operating Systems: A Modern Perspective, Chapter 10

Detection & Recovery Check for deadlock (periodically or sporadically), then recover Can be far more aggressive with allocation No maximum claim, no safe/unsafe states Differentiate between Serially reusable resources: A unit must be allocated before being released Consumable resources: Never release acquired resources; resource count is number currently available Operating Systems: A Modern Perspective, Chapter 10

Reusable Resource Graphs (RRGs)
Micro model to describe a single state Nodes = {p0, p1, …, pn}  {R1, R2, …, Rm} Edges connect pi to Rj, or Rj to pi (pi, Rj) is a request edge for one unit of Rj (Rj, pi) is an assignment edge of one unit of Rj For each Rj there is a count, cj of units Rj Number of units of Rj allocated to pi plus the number requested by pi cannot exceed cj Operating Systems: A Modern Perspective, Chapter 10

State Transitions due to Request
In Sj, pi is allowed to request qch units of Rh, provided pi has no outstanding requests. Sj  Sk, where the RRG for Sk is derived from Sj by adding q request edges from pi to Rh q edges pi Rh pi Rh pi request q units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

State Transition for Acquire
In Sj, pi is allowed to acquire units of Rh, iff there is (pi, Rh) in the graph, and all can be satisfied. Sj  Sk, where the RRG for Sk is derived from Sj by changing each request edge to an assignment edge. pi Rh pi Rh pi acquires units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

State Transition for Release
In Sj, pi is allowed to release units of Rh, iff there is (Rh, pi) in the graph, and there is no request edge from pi. Sj  Sk, where the RRG for Sk is derived from Sj by deleting all assignment edges. pi Rh pi Rh pi releases units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

Example R p P holds one unit of R P requests one unit of R p R A Deadlock State Operating Systems: A Modern Perspective, Chapter 10

Example Not a Deadlock State No Cycle in the Graph Operating Systems: A Modern Perspective, Chapter 10

Example p0 p1 S00 Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p1 p1 S00 S01 Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p0 p1 p1 p1 S00 S01 S11 Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p0 p0 p1 p1 p1 p1 S00 S01 S11 S21 Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p0 p0 p0 p1 p1 p1 p1 p1 S00 S01 S11 S21 S22 Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p0 p0 p0 p0 . . . p1 p1 p1 p1 p1 p1 S00 S01 S11 S21 S22 S33 Operating Systems: A Modern Perspective, Chapter 10

Graph Reduction Deadlock state if there is no sequence of transitions unblocking every process A RRG represents a state; can analyze the RRG to determine if there is a sequence A graph reduction represents the (optimal) action of an unblocked process. Can reduce by pi if pi is not blocked pi has no request edges, and there are (Rj, pi) in the RRG Operating Systems: A Modern Perspective, Chapter 10

Graph Reduction (cont)
Transforms RRG to another RRG with all assignment edges into pi removed Represents pi releasing the resources it holds pi Reducing by pi pi Operating Systems: A Modern Perspective, Chapter 10

Graph Reduction (cont)
A RRG is completely reducible if there a sequence of reductions that leads to a RRG with no edges A state is a deadlock state if and only if the RRG is not completely reducible. Operating Systems: A Modern Perspective, Chapter 10

Example RRG p0 p0 p1 p2 p1 p2 p0 p1 p2 p0 p1 p2 Operating Systems: A Modern Perspective, Chapter 10

Example RRG p0 p1 p2 Operating Systems: A Modern Perspective, Chapter 10

Consumable Resource Graphs (CRGs)
Number of units varies, have producers/consumers Nodes = {p0, p1, …, pn}  {R1, R2, …, Rm} Edges connect pi to Rj, or Rj to pi (pi, Rj) is a request edge for one unit of Rj (Rj, pi) is an producer edge (must have at least one producer for each Rj) For each Rj there is a count, wj of units Rj Operating Systems: A Modern Perspective, Chapter 10

State Transitions due to Request
In Sj, pi is allowed to request any number of units of Rh, provided pi has no outstanding requests. Sj  Sk, where the RRG for Sk is derived from Sj by adding q request edges from pi to Rh q edges pi Rh pi Rh pi request q units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

State Transition for Acquire
In Sj, pi is allowed to acquire units of Rh, iff there is (pi, Rh) in the graph, and all can be satisfied. Sj  Sk, where the RRG for Sk is derived from Sj by deleting each request edge and decrementing wh. pi Rh pi Rh pi acquires units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

State Transition for Release
In Sj, pi is allowed to release units of Rh, iff there is (Rh, pi) in the graph, and there is no request edge from pi. Sj  Sk, where the RRG for Sk is derived from Sj by incrementing wh. pi Rh pi Rh pi releases 2 units State Sj State Sk of Rh Operating Systems: A Modern Perspective, Chapter 10

Example p0 p0 p1 p0 p1 p0 p1 p0 p1 p1 Operating Systems: A Modern Perspective, Chapter 10

Deadlock Detection May have a CRG that is not completely reducible, but it is not a deadlock state For each process: Find at least one sequence which leaves each process unblocked. There may be different sequences for different processes -- not necessarily an efficient approach Operating Systems: A Modern Perspective, Chapter 10

Deadlock Detection May have a CRG that is not completely reducible, but it is not a deadlock state Only need to find sequences, which leave each process unblocked. p0 p1 Operating Systems: A Modern Perspective, Chapter 10

Deadlock Detection May have a CRG that is not completely reducible, but it is not a deadlock state Only need to find a set of sequences, which leaves each process unblocked. Operating Systems: A Modern Perspective, Chapter 10

General Resource Graphs
Have consumable and reusable resources Apply consumable reductions to consumables, and reusable reductions to reusables See Figure 10.29 Operating Systems: A Modern Perspective, Chapter 10

GRG Example (Fig 10.29) p3 p2 R0 R2 R1 p0 p1 Reusable Consumable Not in Fig 10.29 Operating Systems: A Modern Perspective, Chapter 10

GRG Example (Fig 10.29) p3 p2 Reduce by p3 R0 R2 R1 p0 p1 Reusable Consumable Operating Systems: A Modern Perspective, Chapter 10

GRG Example (Fig 10.29) p3 p2 R0  R2 R1 p0 p1 Reduce by p0 Reusable Consumable Operating Systems: A Modern Perspective, Chapter 10

Recovery No magic here Choose a blocked resource Preempt it (releasing its resources) Run the detection algorithm Iterate if until the state is not a deadlock state Operating Systems: A Modern Perspective, Chapter 10

Memory Management Operating Systems: A Modern Perspective, Chapter 11

The External View of the Memory Manager
Application Program sbrk() exec() getrlimit() shmalloc() VMQuery() VirtualFree() VirtualLock() ZeroMemory() VirtualAlloc() File Mgr Device Mgr Memory Mgr Process Mgr File Mgr Device Mgr Memory Mgr Process Mgr UNIX Windows Hardware Operating Systems: A Modern Perspective, Chapter 11

Memory Manager Requirements Minimize executable memory access time Maximize executable memory size Executable memory must be cost-effective Today’s memory manager: Allocates primary memory to processes Maps process address space to primary memory Minimizes access time using cost-effective memory configuration May use static or dynamic techniques Operating Systems: A Modern Perspective, Chapter 11

Storage Hierarchies Less Frequently Used Information More Frequently Used Information Operating Systems: A Modern Perspective, Chapter 11

The Basic Memory Hierarchy
CPU Registers Less Frequently Used Information Primary Memory (Executable Memory) e.g. RAM More Frequently Used Information Secondary Memory e.g. Disk or Tape Operating Systems: A Modern Perspective, Chapter 11

Contemporary Memory Hierarchy & Dynamic Loading
CPU Registers (Executable) Primary L1 Cache Memory L2 Cache Memory “Main” Memory Larger storage Rotating Magnetic Memory Faster access Optical Memory Secondary Sequentially Accessed Memory Operating Systems: A Modern Perspective, Chapter 11

Exploiting the Hierarchy
Upward moves are (usually) copy operations Require allocation in upper memory Image exists in both higher & lower memories Updates are first applied to upper memory Downward move is (usually) destructive Destroy image in upper memory Update image in lower memory Place frequently-used info high, infrequently-used info low in the hierarchy Reconfigure as process changes phases Operating Systems: A Modern Perspective, Chapter 11

Address Space vs Primary Memory
Hardware Primary Memory Process Address Space Mapped to object other than memory Operating Systems: A Modern Perspective, Chapter 11

Creating an Executable Program
Link Edit Library code Other objects Secondary memory Link time: Combine elements Source code C Load time: Allocate primary memory Adjust addresses in address space Copy address space from secondary to primary memory Loader Process address space Primary memory Reloc Object code Compile time: Translate elements Operating Systems: A Modern Perspective, Chapter 11

A Sample Code Segment ... static int gVar; int proc_a(int arg){ gVar = 7; put_record(gVar); } Operating Systems: A Modern Perspective, Chapter 11

The Relocatable Object module
Code Segment Relative Address Generated Code ... 0008 entry proc_a 0220 load =7, R1 0224 store R1, 0036 0228 push 0036 0232 call ‘put_record’ 0400 External reference table 0404 ‘put_record’ 0232 0500 External definition table 0540 ‘proc_a’ 0008 0600 (symbol table) 0799 (last location in the code segment) Data Segment Relative Address Generated variable space ... 0036 [Space for gVar variable] 0049 (last location in the data segment) Operating Systems: A Modern Perspective, Chapter 11

The Absolute Program Code Segment Relative Address Generated Code 0000 (Other modules) ... 1008 entry proc_a 1220 load =7, R1 1224 store R1, 0136 1228 push 1036 1232 call 2334 1399 (End of proc_a) ... (Other modules) 2334 entry put_record 2670 (optional symbol table) 2999 (last location in the code segment) Data Segment Relative Address Generated variable space ... 0136 [Space for gVar variable] 1000 (last location in the data segment) Operating Systems: A Modern Perspective, Chapter 11

The Program Loaded at Location 4000
Relative Address Generated Code 0000 (Other process’s programs) 4000 (Other modules) ... 5008 entry proc_a 5036 [Space for gVar variable] 5220 load =7, R1 5224 store R1, 7136 5228 push 5036 5232 call 6334 5399 (End of proc_a) ... (Other modules) 6334 entry put_record 6670 (optional symbol table) 6999 (last location in the code segment) 7000 (first location in the data segment) 7136 [Space for gVar variable] 8000 (Other process’s programs) Operating Systems: A Modern Perspective, Chapter 11

Static Memory Allocation
Operating System Unused In Use Process 3 Process 0 pi Process 2 Issue: Need a mechanism/policy for loading pi’s address space into primary memory Process 1 Operating Systems: A Modern Perspective, Chapter 11

Fixed-Partition Memory Mechanism
Operating System pi needs ni units Region 0 N0 pi ni Region 1 N1 N2 Region 2 Region 3 N3 Operating Systems: A Modern Perspective, Chapter 11

Fixed-Partition Memory Best-Fit
Operating System Loader must adjust every address in the absolute module when placed in memory Region 0 N0 Region 1 N1 Internal Fragmentation pi N2 Region 2 Region 3 N3 Operating Systems: A Modern Perspective, Chapter 11

Fixed-Partition Memory Worst-Fit
Operating System pi Region 0 N0 Region 1 N1 N2 Region 2 Region 3 N3 Operating Systems: A Modern Perspective, Chapter 11

Fixed-Partition Memory First-Fit
Operating System pi Region 0 N0 Region 1 N1 N2 Region 2 Region 3 N3 Operating Systems: A Modern Perspective, Chapter 11

Fixed-Partition Memory Next-Fit
Operating System Region 0 N0 pi Region 1 N1 Pi+1 N2 Region 2 Region 3 N3 Operating Systems: A Modern Perspective, Chapter 11

Variable Partition Memory
Operating System Process 0 Process 1 Process 2 Process 3 Process 4 Loader adjusts every address in every absolute module when placed in memory Operating System Operating System Process 0 Process 6 Process 2 Process 5 Process 4 Compaction moves program in memory Operating System Process 0 Process 6 Process 2 Process 5 Process 4 External fragmentation Operating Systems: A Modern Perspective, Chapter 11

Cost of Moving Programs
load R1, 0x02010 3F013010 3F016010 Program loaded at 0x04000 Must run loader over program again! Program loaded at 0x01000 Consider dynamic techniques Operating Systems: A Modern Perspective, Chapter 11

C-Style Memory Layout Text Segment Initialized Part Data Segment Uninitialized Part Data Segment Heap Storage Stack Segment Environment Variables, … Operating Systems: A Modern Perspective, Chapter 11

Program and Process Address Spaces
Primary Memory Absolute Program Address Space User Process Address Space Supervisor Process Address Space 3GB 4GB Operating Systems: A Modern Perspective, Chapter 11

Multiprogramming Memory Support
Operating System Unused R0 A In Use B Process 1 R1 C Process 3 R2 D E Process 0 R3 F G Process 1 R4 H Operating Systems: A Modern Perspective, Chapter 11

Dynamic Memory Allocation
Could use dynamically allocated memory Process wants to change the size of its address space Smaller  Creates an external fragment Larger  May have to move/relocate the program Allocate “holes” in memory according to Best- /Worst- / First- /Next-fit Operating Systems: A Modern Perspective, Chapter 11

Memory Mgmt Strategies
Fixed-Partition used only in batch systems Variable-Partition used everywhere (except in virtual memory) Swapping systems Popularized in timesharing Relies on dynamic address relocation Now dated Dynamic Loading (Virtual Memory) Exploit the memory hierarchy Paging -- mainstream in contemporary systems Segmentation -- the future Operating Systems: A Modern Perspective, Chapter 11

Moving an Executable Image
02000 Executable Image Executable Program Loader 06000 Executable Image Loader Operating Systems: A Modern Perspective, Chapter 11

Dynamic Address Relocation
CPU Relative Address 0x02010 0x12010 + Relocation Register 0x10000 load R1, 0x02010 MAR Program loaded at 0x10000  Relocation Register = 0x10000 Program loaded at 0x04000  Relocation Register = 0x04000 We never have to change the load module addresses! Operating Systems: A Modern Perspective, Chapter 11

Multiple Segment Relocation Registers
CPU Relative Address 0x12010 + Code Register Stack Register MAR Data Register Operating Systems: A Modern Perspective, Chapter 11

Runtime Bound Checking
CPU Relative Address + Relocation Register <  Limit Register Bound checking is inexpensive to add Provides excellent memory protection MAR Interrupt Operating Systems: A Modern Perspective, Chapter 11

Special Case: Swapping
Special case of dynamic memory allocation Suppose there is high demand for executable memory Equitable policy might be to time-multiplex processes into the memory (also space-mux) Means that process can have its address space unloaded when it still needs memory Usually only happens when it is blocked Operating Systems: A Modern Perspective, Chapter 11

Swapping Image for pi Swap pi out Swap pj in Image for pj Operating Systems: A Modern Perspective, Chapter 11

Sharing a Portion of the Address Space
Address Space for Process 1 Process 1 Process 2 Primary Memory Address Space for Process 2 Operating Systems: A Modern Perspective, Chapter 11

Figure 11‑26: Multiple Segments
CPU Executing Process 1 Private to Process 1 Limit Relocation Limit Relocation Shared CPU Executing Process 2 Private to Process 2 Limit Relocation Limit Relocation Primary Memory Operating Systems: A Modern Perspective, Chapter 11

Virtual Memory Operating Systems: A Modern Perspective, Chapter 12

Virtual Memory Organization
Primary Memory Secondary Memory Memory Image for pi Operating Systems: A Modern Perspective, Chapter 12

Names, Virtual Addresses & Physical Addresses
Dynamically Executable Image Physical Address Space Bt: Virtual Address Space  Physical Address Space Source Program Absolute Module Name Space Pi’s Virtual Address Space Operating Systems: A Modern Perspective, Chapter 12

Locality Address Space for pi Address space is logically partitioned Text, data, stack Initialization, main, error handle Different parts have different reference patterns: 30% 20% 35% 15% <1% Execution time Initialization code (used once) Code for 1 Code for 2 Code for 3 Code for error 1 Code for error 2 Code for error 3 Data & stack Operating Systems: A Modern Perspective, Chapter 12

Virtual Memory Every process has code and data locality Code tends to execute in a few fragments at one time Tend to reference same set of data structures Dynamically load/unload currently-used address space fragments as the process executes Uses dynamic address relocation/binding Generalization of base-limit registers Physical address corresponding to a compile-time address is not bound until run time Operating Systems: A Modern Perspective, Chapter 12

Virtual Memory (cont) Since binding changes with time, use a dynamic virtual address map, Bt Virtual Address Space Bt Operating Systems: A Modern Perspective, Chapter 12

Virtual Memory Primary Memory n-1 Physical Address Space Fragments of the virtual address space are dynamically loaded into primary memory at any given time Secondary Memory Each address space is fragmented Virtual Address Space for pi Virtual Address Space for pj Virtual Address Space for pk Complete virtual address space is stored in secondary memory Operating Systems: A Modern Perspective, Chapter 12

Address Formation Translation system creates an address space, but its address are virtual instead of physical A virtual address, x: Is mapped to physical address y = Bt(x) if x is loaded at physical address y Is mapped to W if x is not loaded The map, Bt, changes as the process executes -- it is “time varying” Bt: Virtual Address  Physical Address  {W} Operating Systems: A Modern Perspective, Chapter 12

Size of Blocks of Memory
Virtual memory system transfers “blocks” of the address space to/from primary memory Fixed size blocks: System-defined pages are moved back and forth between primary and secondary memory Variable size blocks: Programmer-defined segments – corresponding to logical fragments – are the unit of movement Paging is the commercially dominant form of virtual memory today Operating Systems: A Modern Perspective, Chapter 12

Paging A page is a fixed size, 2h, block of virtual addresses A page frame is a fixed size, 2h, block of physical memory (the same size as a page) When a virtual address, x, in page i is referenced by the CPU If page i is loaded at page frame j, the virtual address is relocated to page frame j If page is not loaded, the OS interrupts the process and loads the page into a page frame Operating Systems: A Modern Perspective, Chapter 12

Addresses Suppose there are G= 2g2h=2g+h virtual addresses and H=2j+h physical addresses assigned to a process Each page/page frame is 2h addresses There are 2g pages in the virtual address space 2j page frames are allocated to the process Rather than map individual addresses Bt maps the 2g pages to the 2j page frames That is, page_framej = Bt(pagei) Address k in pagei corresponds to address k in page_framej Operating Systems: A Modern Perspective, Chapter 12

Page-Based Address Translation
Let N = {d0, d1, … dn-1} be the pages Let M = {b0, b1, …, bm-1} be page frames Virtual address, i, satisfies 0i<G= 2g+h Physical address, k = U2h+V (0V<G= 2h ) U is page frame number V is the line number within the page Bt:[0:G-1]  <U, V>  {W} Since every page is size c=2h page number = U = i/c line number = V = i mod c Operating Systems: A Modern Perspective, Chapter 12

Demand Paging Algorithm
Page fault occurs Process with missing page is interrupted Memory manager locates the missing page Page frame is unloaded (replacement policy) Page is loaded in the vacated page frame Page table is updated Process is restarted Operating Systems: A Modern Perspective, Chapter 12

Modeling Page Behavior
Let R = r1, r2, r3, …, ri, … be a page reference stream ri is the ith page # referenced by the process The subscript is the virtual time for the process Given a page frame allocation of m, the memory state at time t, St(m), is set of pages loaded St(m) = St-1(m)  Xt - Yt Xt is the set of fetched pages at time t Yt is the set of replaced pages at time t Operating Systems: A Modern Perspective, Chapter 12

More on Demand Paging If rt was loaded at time t-1, St(m) = St-1(m) If rt was not loaded at time t-1 and there were empty page frames St(m) = St-1(m)  {rt} If rt was not loaded at time t-1 and there were no empty page frames St(m) = St-1(m)  {rt} - {y} The alternative is prefetch paging Operating Systems: A Modern Perspective, Chapter 12

Static Allocation, Demand Paging
Number of page frames is static over the life of the process Fetch policy is demand Since St(m) = St-1(m)  {rt} - {y}, the replacement policy must choose y -- which uniquely identifies the paging policy Operating Systems: A Modern Perspective, Chapter 12

Address Translation with Paging
g bits h bits Virtual Address Page # Line # “page table” Missing Page Bt j bits h bits Physical Address Frame # Line # CPU Memory MAR Operating Systems: A Modern Perspective, Chapter 12

Random Replacement Replaced page, y, is chosen from the m loaded page frames with probability 1/m Let page reference stream, R = Frame 1 2 2 2 2 3 2 1 3 2 1 3 2 1 3 1 3 1 3 1 2 1 2 3 2 3 2 6 2 4 6 2 4 5 2 7 5 2 No knowledge of R  not perform well Easy to implement 13 page faults Operating Systems: A Modern Perspective, Chapter 12

Belady’s Optimal Algorithm
Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame FWD4(2) = 1 FWD4(0) = 2 FWD4(3) = 3 Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame FWD7(2) = 2 FWD7(0) = 3 FWD7(1) = 1 Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame FWD10(2) =  FWD10(3) = 2 FWD10(1) = 3 Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame FWD13(0) =  FWD13(3) =  FWD13(1) =  Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)FWDt(x) Let page reference stream, R = Frame 10 page faults Perfect knowledge of R  perfect performance Impossible to implement Operating Systems: A Modern Perspective, Chapter 12

Least Recently Used (LRU)
Replace page with maximal forward distance: yt = max xeS t-1(m)BKWDt(x) Let page reference stream, R = Frame BKWD4(2) = 3 BKWD4(0) = 2 BKWD4(3) = 1 Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)BKWDt(x) Let page reference stream, R = Frame Operating Systems: A Modern Perspective, Chapter 12

Replace page with maximal forward distance: yt = max xeS t-1(m)BKWDt(x) Let page reference stream, R = Frame Backward distance is a good predictor of forward distance -- locality Operating Systems: A Modern Perspective, Chapter 12

Least Frequently Used (LFU)
Replace page with minimum use: yt = min xeS t-1(m)FREQ(x) Let page reference stream, R = Frame FREQ4(2) = 1 FREQ4(0) = 1 FREQ4(3) = 1 Operating Systems: A Modern Perspective, Chapter 12

Replace page with minimum use: yt = min xeS t-1(m)FREQ(x) Let page reference stream, R = Frame FREQ6(2) = 2 FREQ6(1) = 1 FREQ6(3) = 1 Operating Systems: A Modern Perspective, Chapter 12

Replace page with minimum use: yt = min xeS t-1(m)FREQ(x) Let page reference stream, R = Frame FREQ7(2) = ? FREQ7(1) = ? FREQ7(0) = ? Operating Systems: A Modern Perspective, Chapter 12

First In First Out (FIFO)
Replace page that has been in memory the longest: yt = max xeS t-1(m)AGE(x) Let page reference stream, R = Frame Operating Systems: A Modern Perspective, Chapter 12

Replace page that has been in memory the longest: yt = max xeS t-1(m)AGE(x) Let page reference stream, R = Frame AGE4(2) = 3 AGE4(0) = 2 AGE4(3) = 1 Operating Systems: A Modern Perspective, Chapter 12

Replace page that has been in memory the longest: yt = max xeS t-1(m)AGE(x) Let page reference stream, R = Frame AGE5(1) = ? AGE5(0) = ? AGE5(3) = ? Operating Systems: A Modern Perspective, Chapter 12

Belady’s Anomaly Let page reference stream, R = Frame Frame FIFO with m = 3 has 9 faults FIFO with m = 4 has 10 faults Operating Systems: A Modern Perspective, Chapter 12

Stack Algorithms Some algorithms are well-behaved Inclusion Property: Pages loaded at time t with m is also loaded at time t with m+1 Frame LRU Frame Operating Systems: A Modern Perspective, Chapter 12

Stack Algorithms Some algorithms are well-behaved Inclusion Property: Pages loaded at time t with m is also loaded at time t with m+1 Frame FIFO Frame Operating Systems: A Modern Perspective, Chapter 12

Implementation LRU has become preferred algorithm Difficult to implement Must record when each page was referenced Difficult to do in hardware Approximate LRU with a reference bit Periodically reset Set for a page when it is referenced Dirty bit Operating Systems: A Modern Perspective, Chapter 12

Dynamic Paging Algorithms
The amount of physical memory -- the number of page frames -- varies as the process executes How much memory should be allocated? Fault rate must be “tolerable” Will change according to the phase of process Need to define a placement & replacement policy Contemporary models based on working set Operating Systems: A Modern Perspective, Chapter 12

Working Set Intuitively, the working set is the set of pages in the process’s locality Somewhat imprecise Time varying Given k processes in memory, let mi(t) be # of pages frames allocated to pi at time t mi(0) = 0 i=1k mi(t)  |primary memory| Also have St(mi(t)) = St(mi(t-1))  Xt - Yt Or, more simply S(mi(t)) = S(mi(t-1))  Xt - Yt Operating Systems: A Modern Perspective, Chapter 12

Placed/Replaced Pages
S(mi(t)) = S(mi(t-1))  Xt - Yt For the missing page Allocate a new page frame Xt = {rt} in the new page frame How should Yt be defined? Consider a parameter, w, called the window size Determine BKWDt(y) for every yS(mi(t-1)) if BKWDt(y)  w, unload y and deallocate frame if BKWDt(y) < w do not disturb y Operating Systems: A Modern Perspective, Chapter 12

Figure 12‑11: The Working Set Window
ri R = … … W=3 The “Window” At virtual time i-1: working set = {0, 1} At virtual time i: working set = {0, 1, 3} Operating Systems: A Modern Perspective, Chapter 12

Working Set Principle Process pi should only be loaded and active if it can be allocated enough page frames to hold its entire working set The size of the working set is estimated using w Unfortunately, a “good” value of w depends on the size of the locality Empirically this works with a fixed w Operating Systems: A Modern Perspective, Chapter 12

Example (w = 3) Frame 0 0 # 1 Operating Systems: A Modern Perspective, Chapter 12

Example (w = 4) Frame 0 0 # 1 Operating Systems: A Modern Perspective, Chapter 12

Implementing the Working Set
Global LRU will behave similarly to a working set algorithm Page fault Add a page frame to one process Take away a page frame from another process Use LRU implementation idea Reference bit for every page frame Cleared periodically, set with each reference Change allocation of some page frame with a clear reference bit Clock algorithms use this technique by searching for cleared ref bits in a circular fashion Operating Systems: A Modern Perspective, Chapter 12

Windows NT Paging System
Reference to Address k in Page i (User space) Virtual Address Space Lookup (Page i, Addr k) Reference (Page Frame j, Addr k) Primary Memory Translate (Page i, Addr k) to (Page Frame j, Addr k) Paging Disk (Secondary Memory) Supv space User space Operating Systems: A Modern Perspective, Chapter 12

Windows Address Translation
Virtual page number Line number Page Directory Page Table Byte Index a b A Page Directory c B Page Tables C Target Page Target Byte Operating Systems: A Modern Perspective, Chapter 12

Linux Virtual Address Translation

Segmentation Unit of memory movement is: Variably sized Defined by the programmer Two component addresses, <Seg#, offset> Address translation is more complex than paging Bt: segments x offsets  Physical Address  {W} Bt(i, j) = k Operating Systems: A Modern Perspective, Chapter 12

Inter Segment References
using segmentA … call lab1 call [segmentC, lab20] lab1: … using segmentB using segmentC lab20: … Operating Systems: A Modern Perspective, Chapter 12

Segment Address Translation
Bt: segments x offsets  physical address  {W} Bt(i, j) = k S: segments  segment addresses Bt(S(segName), j) = k N: offset names  offset addresses Bt(S(segName), N(offsetName)) = k Read implementation in Section 12.6 Operating Systems: A Modern Perspective, Chapter 12

Address Translation in Segmentation
<segmentName, offsetName> S N segment # offset ? Limit Bt Relocation Missing segment + Limit Base P To Memory Address Register Operating Systems: A Modern Perspective, Chapter 12

Implementation Segmentation requires special hardware Segment descriptor support Segment base registers (segment, code, stack) Translation hardware Some of translation can be static No dynamic offset name binding Limited protection Operating Systems: A Modern Perspective, Chapter 12

Multics Old, but still state-of-the-art segmentation Uses linkage segments to support sharing Uses dynamic offset name binding Requires sophisticated memory management unit See Section 12.6 Operating Systems: A Modern Perspective, Chapter 12

NT Memory-mapped Files
Secondary memory Ordinary file Open the file Create a section object (that maps file) Identify point in address space to place the file Executable memory Memory mapped files Section object Operating Systems: A Modern Perspective, Chapter 12

NT Memory-mapped Files(2)

File Management Operating Systems: A Modern Perspective, Chapter 13

Fig 13-2: The External View of the File Manager
Application Program CreateFile() ReadFile() CloseHandle() SetFilePointer() WriteFile() mount() write() open() close() read() lseek() File Mgr Device Mgr Memory Mgr Process Mgr File Mgr Device Mgr Memory Mgr Process Mgr UNIX Windows Hardware Operating Systems: A Modern Perspective, Chapter 13

Why Programmers Need Files
<head> … </head> <body> </body> HTML Editor Web Browser Structured information Can be read by any applic Accessibility Protocol <head> … </head> <body> </body> foo.html File Manager Persistent storage Shared device Operating Systems: A Modern Perspective, Chapter 13

File Management File is a named, ordered collection of information The file manager administers the collection by: Storing the information on a device Mapping the block storage to a logical view Allocating/deallocating storage Providing file directories What abstraction should be presented to programmer? Operating Systems: A Modern Perspective, Chapter 13

Information Structure
Applications Records Structured Record Files Record-Stream Translation Byte Stream Files Stream-Block Translation Storage device Operating Systems: A Modern Perspective, Chapter 13

Byte Stream File Interface
fileID = open(fileName) close(fileID) read(fileID, buffer, length) write(fileID, buffer, length) seek(fileID, filePosition) Operating Systems: A Modern Perspective, Chapter 13

Low Level Files fid = open(“fileName”,…); … read(fid, buf, buflen); close(fid); ... ... b0 b1 b2 bi int open(…) {…} int close(…) {…} int read(…) {…} int write(…) {…} int seek(…) {…} Stream-Block Translation Storage device response to commands Operating Systems: A Modern Perspective, Chapter 13

Structured Files Records Record-Block Translation Operating Systems: A Modern Perspective, Chapter 13

Record-Oriented Sequential Files
Logical Record fileID = open(fileName) close(fileID) getRecord(fileID, record) putRecord(fileID, record) seek(fileID, position) Operating Systems: A Modern Perspective, Chapter 13

Logical Record H byte header k byte logical record ... Operating Systems: A Modern Perspective, Chapter 13

Logical Record H byte header k byte logical record ... ... Physical Storage Blocks Fragment Operating Systems: A Modern Perspective, Chapter 13

Electronic Mail Example
struct message { /* The mail message */ address to; address from; line subject; address cc; string body; }; struct message *getRecord(void) { struct message *msg; msg = allocate(sizeof(message)); msg->to = getAddress(...); msg->from = getAddress(...); msg->cc = getAddress(...); msg->subject = getLine(); msg->body = getString(); return(msg); } putRecord(struct message *msg) { putAddress(msg->to); putAddress(msg->from); putAddress(msg->cc); putLine(msg->subject); putString(msg->body); } Operating Systems: A Modern Perspective, Chapter 13

Indexed Sequential File
Suppose we want to directly access records Add an index to the file fileID = open(fileName) close(fileID) getRecord(fileID, index) index = putRecord(fileID, record) deleteRecord(fileID, index) Operating Systems: A Modern Perspective, Chapter 13

Indexed Sequential File (cont)
Application structure index = i Account # 012345 123456 294376 ... 529366 965987 Index i k j index = k index = j Operating Systems: A Modern Perspective, Chapter 13

More Abstract Files Inverted files System index for each datum in the file Databases More elaborate indexing mechanism DDL & DML Multimedia storage Records contain radically different types Access methods must be general Operating Systems: A Modern Perspective, Chapter 13

Implementing Low Level Files
Secondary storage device contains: Volume directory (sometimes a root directory for a file system) External file descriptor for each file The file contents Manages blocks Assigns blocks to files (descriptor keeps track) Keeps track of available blocks Maps to/from byte stream Operating Systems: A Modern Perspective, Chapter 13

Disk Organization Boot Sector Volume Directory Blk0 Blk1 … Blkk-1 Track 0, Cylinder 0 … Blkk Blkk+1 Blk2k-1 Track 0, Cylinder 1 … … Blk Blk Blk Track 1, Cylinder 0 … … Blk Blk Blk Track N-1, Cylinder 0 … … Blk Blk Blk Track N-1, Cylinder M-1 Operating Systems: A Modern Perspective, Chapter 13

Low-level File System Architecture
Block 0 b0 b1 b2 b3 … … bn-1 . . . Sequential Device Randomly Accessed Device Operating Systems: A Modern Perspective, Chapter 13

File Descriptors External name Current state Sharable Owner User Locks Protection settings Length Time of creation Time of last modification Time of last access Reference count Storage device details Operating Systems: A Modern Perspective, Chapter 13

An open() Operation Locate the on-device (external) file descriptor Extract info needed to read/write file Authenticate that process can access the file Create an internal file descriptor in primary memory Create an entry in a “per process” open file status table Allocate resources, e.g., buffers, to support file usage Operating Systems: A Modern Perspective, Chapter 13

File Manager Data Structures
Keep the state of the process-file session 2 Copy info from external to the open file descriptor 1 Open File Descriptor Process-File Session 3 Return a reference to the data structure External File Descriptor Operating Systems: A Modern Perspective, Chapter 13

Opening a UNIX File fid = open(“fileA”, flags); … read(fid, buffer, len); On-Device File Descriptor 0 stdin 1 stdout 2 stderr 3 ... File structure inode Open File Table Internal File Descriptor Operating Systems: A Modern Perspective, Chapter 13

Block Management The job of selecting & assigning storage blocks to the file For a fixed sized file of k blocks File of length m requires N = m/k blocks Byte bi is stored in block i/k Three basic strategies: Contiguous allocation Linked lists Indexed allocation Operating Systems: A Modern Perspective, Chapter 13

Contiguous Allocation
Maps the N blocks into N contiguous blocks on the secondary storage device Difficult to support dynamic file sizes File descriptor Head position 237 … First block 785 Number of blocks 25 Operating Systems: A Modern Perspective, Chapter 13

Linked Lists Each block contains a header with Number of bytes in the block Pointer to next block Blocks need not be contiguous Files can expand and contract Seeks can be slow First block … Head: 417 ... Length Length Length Byte 0 Byte 0 Byte 0 ... ... ... Byte 4095 Byte 4095 Byte 4095 Block 0 Block 1 Block N-1 Operating Systems: A Modern Perspective, Chapter 13

Indexed Allocation Extract headers and put them in an index Simplify seeks May link indices together (for large files) Byte 0 ... Index block … Head: 417 ... Byte 4095 Length Block 0 Length Byte 0 ... Byte 4095 Block 1 Byte 0 ... Length Byte 4095 Block N-1 Operating Systems: A Modern Perspective, Chapter 13

DOS FAT Files File Descriptor 43 254 … 107 Disk Block Disk Block Disk Block File Access Table (FAT) Disk Block … 43 107 254 File Descriptor Operating Systems: A Modern Perspective, Chapter 13

UNIX Files inode mode owner … Direct block 0 Direct block 1 Direct block 11 Single indirect Double indirect Triple indirect Data Data Data Index Data Index Data Index Data Operating Systems: A Modern Perspective, Chapter 13

Unallocated Blocks How should unallocated blocks be managed? Need a data structure to keep track of them Linked list Very large Hard to manage spatial locality Block status map (“disk map”) Bit per block Easy to identify nearby free blocks Useful for disk recovery Operating Systems: A Modern Perspective, Chapter 13

Marshalling the Byte Stream
Must read at least one buffer ahead on input Must write at least one buffer behind on output Seek  flushing the current buffer and finding the correct one to load into memory Inserting/deleting bytes in the interior of the stream Operating Systems: A Modern Perspective, Chapter 13

Full Block Buffering Storage devices use block I/O Files place an explicit order on the bytes Therefore, it is possible to predict what is likely to be read after bytei When file is opened, manager reads as many blocks ahead as feasible After a block is logically written, it is queued for writing behind, whenever the disk is available Buffer pool – usually variably sized, depending on virtual memory needs Interaction with the device manager and memory manager Operating Systems: A Modern Perspective, Chapter 13

Directories A set of logically associated files and sub directories File manager provides set of controls: enumerate copy rename delete traverse etc. Operating Systems: A Modern Perspective, Chapter 13

Directory Structures How should files be organized within directory? Flat name space All files appear in a single directory Hierarchical name space Directory contains files and subdirectories Each file/directory appears as an entry in exactly one other directory -- a tree Popular variant: All directories form a tree, but a file can have multiple parents. Operating Systems: A Modern Perspective, Chapter 13

Directory Implementation
Device Directory A device can contain a collection of files Easier to manage if there is a root for every file on the device -- the device root directory File Directory Typical implementations have directories implemented as a file with a special format Entries in a file directory are handles for other files (which can be files or subdirectories) Operating Systems: A Modern Perspective, Chapter 13

UNIX mount Command / bin usr etc foo bill nutt abc blah cde xyz mount FS at foo FS / bin usr etc foo bill nutt / FS abc cde xyz blah Operating Systems: A Modern Perspective, Chapter 13

VFS-based File Manager
Exports OS-specific API File System Independent Part of File Manager Virtual File System Switch MS-DOS Part of File Manager ISO 9660 Part of File Manager … ext2 Part of File Manager Operating Systems: A Modern Perspective, Chapter 13

Protection and Security
14 Protection and Security Operating Systems: A Modern Perspective, Chapter 5

Allowing Only Authorized Access
Authentication Authorization Subject Unauthorized Access Secure Entity Subject Operating Systems: A Modern Perspective, Chapter 5

Policy & Mechanism Protection mechanisms are tools used to implement security policies Authentication Authorization Cryptography A security policy reflects an organization’s strategy for authorizing access to the computer’s resources only to authenticated parties Accountants have access to payroll files OS processes have access to the page table Client process has access to information provided by a server Operating Systems: A Modern Perspective, Chapter 5

Cryptographically Protected Information
Secure Container Secure Element Secure Element Secure Environment Secure Environment Operating Systems: A Modern Perspective, Chapter 5

Windows 2000 Logon Local Security Authority Subsystem (Lsass) Winlogon
process LSA* Server Netlogon Network Authentic. LSA Policy Active Directory SAM Active Directory SAM** Server User Space Supervisor Space Security Reference Monitor (SRM) * Local Security Authority ** Security Accounts Manager (SAM) Operating Systems: A Modern Perspective, Chapter 5

Security Goals Machine X Resource X Resource W Resource Y Resource Z Process A read read read/write Process B read/write Authentication Machine Y Authorization Process C Operating Systems: A Modern Perspective, Chapter 5

Authentication User/process authentication Is this user/process who it claims to be? Passwords More sophisticated mechanisms Authentication in networks Is this computer who it claims to be? File downloading Obtaining network services The Java promise Operating Systems: A Modern Perspective, Chapter 5

Authorization Is this user/process allowed to access the resource under the current policy? What type of access is allowable? Read Write Execute Append Operating Systems: A Modern Perspective, Chapter 5

Lampson’s Protection Model
Active parts (e.g., processes) Operate in different domains Subject is a process in a domain Passive parts are called objects Want mechanism to implement different security policies for subjects to access objects Many different policies must be possible Policy may change over time Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects a S X S desires a access to X Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects Protection State S X S desires a access to X Protection state reflects current ability to access X Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects Protection State S X State Transition S desires a access to X Protection state reflects current ability to access X Authorities can change Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects Protection State S X State Transition S desires a access to X Protection state reflects current ability to access X Authorities can change What are rules for changing authority? Rules Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects Protection State S X State Transition S desires a access to X Protection state reflects current ability to access X Authorities can change What are rules for changing authority? How are the rules chosen? Rules Policy Operating Systems: A Modern Perspective, Chapter 5

Protection System Example
S desires a access to X Operating Systems: A Modern Perspective, Chapter 5

S desires a access to X Captures the protection state S a Access matrix Operating Systems: A Modern Perspective, Chapter 5

(S, a, X) Access authentication S X X S desires a access to X Captures the protection state Generates an unforgeable ID S a Access matrix Operating Systems: A Modern Perspective, Chapter 5

(S, a, x) Access authentication Monitor S X X S desires a access to X Captures the protection state Generates an unforgeable ID Checks the access against the protection state S a Operating Systems: A Modern Perspective, Chapter 5

Protection State Example
F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner Operating Systems: A Modern Perspective, Chapter 5

A Protection System Subjects Objects Protection State S X State Transition Rules Handling state changes Policy Operating Systems: A Modern Perspective, Chapter 5

Policy Rules Example S1 S2 S3 F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner Rules for a Particular Policy Rule Command by S0 Authorization Effect 1 transfer(a|a*) to (S, X) a*A[S0, X] A[S, X] = A[S, X]{a|a*} 2 grant(a|a*) to (S, X) ownerA[S0, X] A[S, X] = A[S, X]{a|a*} 3 delete a from (S, X) controlA[S0, S] A[S, X] = A[S, X]-{a} or ownerA[S0, X] Operating Systems: A Modern Perspective, Chapter 5

Protection Domains Lampson model uses processes and domains -- how is a domain implemented? Supervisor/user hardware mode bit Software extensions -- rings Inner rings have higher authority Ring 0 corresponds to supervisor mode Rings 1 to S have decreasing protection, and are used to implement the OS Rings S+1 to N-1 have decreasing protection, and are used to implement applications Operating Systems: A Modern Perspective, Chapter 5

Protection Domains (cont)
Ring crossing is a domain change Inner ring crossing  rights amplification Specific gates for crossing Protected by an authentication mechanism Outer ring crossing uses less-protected objects No authentication Need a return path Used in Multics and Intel (& above) hardware Operating Systems: A Modern Perspective, Chapter 5

A Two-level Domain Architecture
Supv User Operating Systems: A Modern Perspective, Chapter 5

The General Ring Architecture
… Ri Operating Systems: A Modern Perspective, Chapter 5

Implementing the Access Matrix
Usually a sparse matrix Too expensive to implement as a table Implement as a list of table entries Column oriented list is called an access control list (ACL) List kept at the object UNIX file protection bits are one example Row oriented list is a called a capability list List kept with the subject (i.e., process) Kerberos ticket is a capability Mach mailboxes protected with capabilities Operating Systems: A Modern Perspective, Chapter 5

Access Control Lists Derived from an Access Matrix
Store the Access Matrix by columns Each ACL is kept at the object UNIX file protection bits are one example Windows resource managers also use ACLs for protection S a a a X a X a X a Resource Descriptor Resource Descriptor Resource Descriptor Operating Systems: A Modern Perspective, Chapter 5

Capability Lists Derived from an Access Matrix
Store the Access Matrix by rows List kept with the subject (i.e., process) Examples Ticket to a concert Kerberos ticket Mach mailboxes S a S a S a S a Process Descriptor S a Process Descriptor a S Process Descriptor Operating Systems: A Modern Perspective, Chapter 5

More on Capabilities Provides an address to object from a very large address space Possession of a capability represents authorization for access Implied properties: Capabilities must be very difficult to guess Capabilities must be unique and not reused Capabilities must be distinguishable from randomly generated bit patterns Operating Systems: A Modern Perspective, Chapter 5

Cryptography Information can be encoded using a key when it is written (or transferred) -- encryption It is then decoded using a key when it is read (or received) -- decryption Very widely used for secure network transmission Operating Systems: A Modern Perspective, Chapter 5

More on Cryptography encryption plaintext ciphertext decryption Operating Systems: A Modern Perspective, Chapter 5

More on Cryptography Ke Kd C = EKe(plaintext) Encrypt Decrypt plaintext plaintext Operating Systems: A Modern Perspective, Chapter 5

More on Cryptography Ke Kd C = EKe(plaintext) Encrypt Decrypt plaintext plaintext Invader Side information plaintext Operating Systems: A Modern Perspective, Chapter 5

Cryptographic Systems
Modern Systems Conventional Systems Ke and Kd are essentially the same Private Key Public Key Ke and Kd are private Ke is public Kd is private Operating Systems: A Modern Perspective, Chapter 5

Kerberos Authentication Server Client Server Operating Systems: A Modern Perspective, Chapter 5

Kerberos Authentication Server Encrypted for client Encrypted for server Ticket Client Client ID Session Key Session Key Server Operating Systems: A Modern Perspective, Chapter 5

Kerberos Authentication Server Encrypted for client Encrypted for server Ticket Session Key Client Client ID Session Key Session Key Server Operating Systems: A Modern Perspective, Chapter 5

Kerberos Authentication Server Encrypted for client Encrypted for server Ticket Session Key Client Client ID Session Key Session Key Ticket Server Client ID Session Key Client ID Session Key Operating Systems: A Modern Perspective, Chapter 5

The DES Algorithm Plain Text 64-bit Block IP 64-bit Block Lj-1 Rj-1 f Kj = j(K, j)  Rj-1 Rj-1 64-bit Block IP-1 64-bit Block Operating Systems: A Modern Perspective, Chapter 5

A Digital Rights Management System
Publisher Distributor, etc Style Editor Rights Editor Other parties may contribute to rights spec Raw Style Rights Translate Client API Content Repository Query Consumer Admin API Distribute Serve InTransit Server Playback Consumable Operating Systems: A Modern Perspective, Chapter 5

Remote Files Operating Systems: A Modern Perspective, Chapter 16

Traditional Memory Interfaces
Process Primary Memory Interface File System Interface Virtual Memory Privileged Use Only File Management Device Interface Physical Memory Storage Devices Operating Systems: A Modern Perspective, Chapter 16

Remote Memory Y Remote Primary Memory Remote Secondary Memory Y Network Y Network von Neumann Architecture Operating Systems: A Modern Perspective, Chapter 16

Explicit File Copying Need a way for a process on one machine to pass info to a process on another machine Technique Sender writes a file User manually copies file to a remote machine Receiver opens the file and reads it Very coarse grained Very high latency Operating Systems: A Modern Perspective, Chapter 16

Distributed Computation Using Files
f2 = open(toPart1, …); while(…){ read(f2, …); } close(f2); Part 1 … f2 = open(toPart1, …); while(…){ write(f2. …); } close(f2); Part 2 f1 = open(toPart2, …); while(…){ write(f1. …); } close(f1); f2 = open(toPart2, …); while(…){ read(f1, …); } close(f1); Operating Systems: A Modern Perspective, Chapter 16

Client-Server Manual File Copy
1 get FILE_A Client Process Server Process Copy FILE_A to the client 2 FILE_A Data flow Control flow Operating Systems: A Modern Perspective, Chapter 16

Using the Secondary Memory Interface for Remote Secondary Memory
Process Secondary Memory Interface File Management Comm Network Client Interface to Remote Store Device Interface Storage Devices Operating Systems: A Modern Perspective, Chapter 16

VFS-based File Manager
Exports OS-specific API File System Independent Part of File Manager Virtual File System Switch Dependent Part of File System A … … Dependent Part of Remote File System Operating Systems: A Modern Perspective, Chapter 16

The Remote File Client and Server
Client Machine Process File System Interface File System Dependent Part for Remote Disk/File System File Independent Functions Server Machine File System Dependent Remote File Client Remote File Server Storage Devices Comm Network Storage Devices Operating Systems: A Modern Perspective, Chapter 16

A Shared Remote Disk Server
File descriptor mgmt. Marshall/unmarshall Buffering Block management … Client Machine File Independent Functions Server Machine Remote File System Dependent Part File System Dependent Part Remote Disk Application Virtual Disk Driver Storage Devices Comm Network Storage Devices Operating Systems: A Modern Perspective, Chapter 16

Remote Disk Server file mgr: diskRequest(details); VDD: Pack parameters; VDD: Send request; (wait for response) (waiting for a request) RDA: Unpack parameters; RDA: Generate local disk request; (waiting) RDA: Generate reply; RDA: Send reply VDD: Receive reply; VDD: Unpack parameters; VDD: Return to file mgr Client Machine General File Management Server Machine Virtual Disk Driver Remote Disk Application Storage Devices Comm Network Storage Devices Operating Systems: A Modern Perspective, Chapter 16

Exploiting Remote Disks
Diskless UNIX workstation X Terminal Network computer (“thin client”) WebTV Palmtops, tablets, PDAs, cell phones, … Operating Systems: A Modern Perspective, Chapter 16

Performance & Reliability
Became commercially feasible in about 1986 Biggest concern was reliability Use datagrams for performance How can the system assure that commands get executed? If the server crashes: How can we prevent “incomplete transactions”? How can the client resume its operation? Operating Systems: A Modern Perspective, Chapter 16

Reliable Command Execution
Using request time-outs Issue command Wait for a fixed t Re-issue the command Failed command send operation Re-issue is appropriate Failed command ACK operation Is re-issued command appropriate? Idempotent operations Operating Systems: A Modern Perspective, Chapter 16

Crash Recovery Distributed state Client’s view of open files Server’s view of open files Distribution  less network traffic Distribution  recovering state is difficult Server must have stable memory Can be built without special hardware, but expensive Stateless servers All state is kept at the client All operations are idempotent Stateless server  more network traffic Stateless server  no server-side state recovery Operating Systems: A Modern Perspective, Chapter 16

Another Partition of the File Manager Functionality
Client Machine File Independent Functions Server Machine Remote File Server Device Management Buffering Block management Remote File Client Marshall/unmarshall Buffering File System Dependent Part Storage Devices Comm Network Storage Devices Operating Systems: A Modern Perspective, Chapter 16

Block Caching Widely used in all file systems In RFS can buffer at: Server Doesn’t avoid network latency Client Consistency Sometimes use sequential write consistency (no sharing if there are multiple writers) Operating Systems: A Modern Perspective, Chapter 16

Crash Recovery Client has a file open and server crashes Distributed state makes recovery difficult Can counteract with a stateless server But it requires that state be transmitted with every service request Recovery-oriented file service, e.g., Sun NFS Performance-oriented file service Operating Systems: A Modern Perspective, Chapter 16

Buffering in a Remote File System
Client Part of File Service Server Part of File Service Disk Block Disk Block Disk Block Disk Block Read Write Read Write Operating Systems: A Modern Perspective, Chapter 16

File-Level Caching Copy an entire file to the client when it is needed Requires enough client storage to hold any file Widely-used in contemporary palmtops File Consistency Synchronization on any file write operation Immutable files Operating Systems: A Modern Perspective, Chapter 16

Directories -- Pathnames
Need a path through the internet to host in addition to path from root at the host goober:/usr/bernie/good/stuff /../goober/usr/bernie/good/stuff Remote mounting Mount a file system on a remote host (use a superpathname to reference server) Use normal path names Operating Systems: A Modern Perspective, Chapter 16

A Remotely Mounted File System
Machine R / Machine S usr … bin etc / zip mt_pt usr … bin etc mount s_mnt s_hop Operating Systems: A Modern Perspective, Chapter 16

Opening a File Machine R / Machine S usr … bin etc / zip mt_pt usr … bin etc Machine T mount s_mnt / s_hop mount usr … bin etc zip t_mnt t_file Operating Systems: A Modern Perspective, Chapter 16

Design Strategies Operating Systems: A Modern Perspective, Chapter 19

Software Organization
Application Software Application Software Application Software Application Software Other System Software Other System Software Other System Software Other System Software Other OS Functions Other OS Functions Other OS Functions Other OS Functions Kernel Functions Nucleus Functions Nucleus Functions Nucleus Functions Skeletal Nucleus (a) Monolithic (b) Modular (c) Extensible (d) Layered Operating Systems: A Modern Perspective, Chapter 19

Figure 19‑2: OS Function Organization
File Manager Process & Resource Manager Memory Manager Device Manager Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 19

Function Interactions
Process/Thread Admin Virtual Memory Scheduler File Management Synchronization Device Management IPC Deadlock Management Interrupt Handler Resource Management Protection Mechanisms Memory Allocation Operating Systems: A Modern Perspective, Chapter 19

Multiple OS Policies on a Single Hardware Architecture
… OS Policy Implementation OS Policy Implementation OS Policy Implementation Virtual Machine Interface Extensible Kernel Hardware Popularized in IBM VM Approach is used in Windows NT Subsystems Operating Systems: A Modern Perspective, Chapter 19

Porting an OS to Different Architectures
OS Policy Implementation Extensible Kernel Architecture Adaptor … Hardware Architecture 1 Hardware Architecture 2 Hardware Architecture N Used in Windows NT Technology Used in Linux (sort of …) Operating Systems: A Modern Perspective, Chapter 19

Mach Microkernel-based OS
BSD 4.3 Implementation OSF/1 Implementation RT-Mach Implementation … OS Policy Implementation Mach Kernel Interface Mach Microkernel (Tasks, Threads, Ports, …) Hardware Operating Systems: A Modern Perspective, Chapter 19

Transferring Large Messages in Accent
send(receiver, …); Sender Receiver Message Object … … Message Object Sender’s Page Table Receiver’s Page Table Operating Systems: A Modern Perspective, Chapter 19

Kernel-Based Page Replacement
Secondary Memory Kernel Space Page Replacement New Page Load page Fault Handler Update Map Page Fault Page Frame 0 Page Frame 1 … Virtual Address Physical Address Processor MMU … Primary Memory Operating Systems: A Modern Perspective, Chapter 19

Mach Memory Page Replacement
The replacement policy can be specified by a user space program Secondary Memory Page Replacement Kernel Space Load page Fault Handler Page Frame 0 Update Map Page Fault Page Frame 1 … Virtual Address Physical Address Processor MMU New Page … Primary Memory Operating Systems: A Modern Perspective, Chapter 19

Binding Memory Objects
Arbitrary Object Mem Obj Manager Kernel Space Conventional Page Objects Kernel Mem Obj Mgr Virtual Address User Space Application Operating Systems: A Modern Perspective, Chapter 19

The CHORUS Microkernel and Servers
Sys V UNIX Implementation COOL Implementation RT-OS Implementation … OS Policy Implementation CHORUS Kernel Interface Chorus Microkernel (Actors, Threads, Ports, …) Hardware Operating Systems: A Modern Perspective, Chapter 19

The Windows NT/2000/XP Kernel
21 The Windows NT/2000/XP Kernel Operating Systems: A Modern Perspective, Chapter 21

Windows NT/2000 Organization
Subsystem Subsystem Subsystem User Supervisor I/O Subsystem NT Executive NT Kernel Hardware Abstraction Layer Processor(s) Main Memory Devices Operating Systems: A Modern Perspective, Chapter 21

Windows NT Trap Handler

Handles, Executive Objects and Kernel Objects

Process and Thread Descriptors

Virtual Memory Operating Systems: A Modern Perspective, Chapter 21

The I/O Manager Operating Systems: A Modern Perspective, Chapter 21

A Cached Read Operation

Asynchronous Read Operating Systems: A Modern Perspective, Chapter 21

The Win32 API Win32 API Win32 Subsystem Native NT API NT Executive & NT Kernel Operating Systems: A Modern Perspective, Chapter 21

Operating Systems: A Modern Perspective, Chapter 1

Similar presentations

Presentation on theme: "Operating Systems: A Modern Perspective, Chapter 1"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Operating Systems: A Modern Perspective, Chapter 1

Similar presentations

Presentation on theme: "Operating Systems: A Modern Perspective, Chapter 1"— Presentation transcript:

Similar presentations

About project

Feedback