CS370 Opera;ng Systems Midterm Review. Yashwant K Malaiya Spring 2018

Similar documents
CS370 Operating Systems Midterm Review. Yashwant K Malaiya Spring 2019

CS370 Operating Systems Midterm Review

CSE Opera,ng System Principles

Lesson 6: Process Synchronization

Chapter 5: Process Synchronization

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

CHAPTER 6: PROCESS SYNCHRONIZATION

Process Synchronization

Chapter 6: Process Synchronization

Chapter 5: Process Synchronization

Chapter 6: Synchronization. Chapter 6: Synchronization. 6.1 Background. Part Three - Process Coordination. Consumer. Producer. 6.

Chapter 7: Process Synchronization!

CS370 Operating Systems

Process Synchronization

CS370 Operating Systems

Synchronization Principles

Chapter 6: Process Synchronization

CS370 Operating Systems

Chapter 5: Process Synchronization

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

Process Synchronization. CISC3595, Spring 2015 Dr. Zhang

Chapter 5: Process Synchronization. Operating System Concepts Essentials 2 nd Edition

Module 6: Process Synchronization

Chapter 6: Process Synchronization. Operating System Concepts 8 th Edition,

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

Chapter 7: Process Synchronization. Background. Illustration

Process Synchronization

Chapter 7: Process Synchronization. Background

EI 338: Computer Systems Engineering (Operating Systems & Computer Architecture)

Process Synchronization

Real-Time Operating Systems M. 5. Process Synchronization

Chapter 6: Process Synchronization. Operating System Concepts 9 th Edit9on

Process Synchronization

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

Chapter 6: Process Synchronization. Module 6: Process Synchronization

Chapter 6: Process Synchronization

Chapter 6: Synchronization. Operating System Concepts 8 th Edition,

CS420: Operating Systems. Process Synchronization

UNIT 2 Basic Concepts of CPU Scheduling. UNIT -02/Lecture 01

Chapter 6: Process Synchronization

Chapter 6 Synchronization

Maximum CPU utilization obtained with multiprogramming. CPU I/O Burst Cycle Process execution consists of a cycle of CPU execution and I/O wait

Synchronization Principles II

Introduction to Operating Systems

COP 4225 Advanced Unix Programming. Synchronization. Chi Zhang

Chapter 6: Synchronization

Lecture 5: Inter-process Communication and Synchronization

CS370 Operating Systems

Chapter 6 Process Synchronization

Chapter 6: Process Synchronization

Process Synchronization

CS370: System Architecture & Software [Fall 2014] Dept. Of Computer Science, Colorado State University

Synchronization. CS 475, Spring 2018 Concurrent & Distributed Systems

UNIT II PROCESS MANAGEMENT 9

Process Co-ordination OPERATING SYSTEMS

CS370 Operating Systems

Process Synchronization

Processes-Process Concept:

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

OPERATING SYSTEMS. UNIT II Sections A, B & D. An operating system executes a variety of programs:

Lecture 3: Synchronization & Deadlocks

Process Coordination

$ %! 0,-./ + %/ 0"/ C (" &() + A &B' 7! .+ N!! O8K + 8 N. (Monitors) 3+!

Chapter 3: Process Concept

Chapter 3: Process Concept

Chapter 3: Process Concept

CS370 Operating Systems

Processes. Rafael Ramirez Dep Tecnologia Universitat Pompeu Fabra

CSC Operating Systems Spring Lecture - XII Midterm Review. Tevfik Ko!ar. Louisiana State University. March 4 th, 2008.

Unit 1: Introduction

PESIT Bangalore South Campus

CHAPTER 2: PROCESS MANAGEMENT

Chapter 3: Processes

Chapter 3: Process-Concept. Operating System Concepts 8 th Edition,

Lecture 2 Process Management

CSE 4/521 Introduction to Operating Systems

CS370 Operating Systems

Background. The Critical-Section Problem Synchronisation Hardware Inefficient Spinning Semaphores Semaphore Examples Scheduling.

Chapter 6: Process Synchronization. Operating System Concepts 8 th Edition,

Chapter 3: Processes

Process Synchronization

Dept. of CSE, York Univ. 1

Interprocess Communication By: Kaushik Vaghani

Synchronization Spinlocks - Semaphores

CS370 Operating Systems

CS370 Operating Systems

Process Synchronization

Synchronization. Race Condition. The Critical-Section Problem Solution. The Synchronization Problem. Typical Process P i. Peterson s Solution

Midterm Review. CSE 120: Principles of Opera=ng Systems. UC San Diego: Summer Session I, 2009 Frank Uyeda

Processes. CS 475, Spring 2018 Concurrent & Distributed Systems

Comp 310 Computer Systems and Organization

Process. Heechul Yun. Disclaimer: some slides are adopted from the book authors slides with permission 1

TDIU25: Operating Systems II. Processes, Threads and Scheduling

CS370 Operating Systems

Module 6: Process Synchronization

Background. Module 6: Process Synchronization. Bounded-Buffer (Cont.) Bounded-Buffer. Background

Synchronization for Concurrent Tasks

Operating Systems. Figure: Process States. 1 P a g e

Che-Wei Chang Department of Computer Science and Information Engineering, Chang Gung University

Lecture 2: Processes. CSE 120: Principles of Opera9ng Systems. UC San Diego: Summer Session I, 2009 Frank Uyeda

Transcription:

CS370 Opera;ng Systems Midterm Review Yashwant K Malaiya Spring 2018 1 1

Computer System Structures Computer System Opera2on Stack for calling func2ons (subrou2nes) I/O Structure: polling, interrupts, DMA Storage Structure Storage Hierarchy System Calls and System Programs Command Interpreter 2 2

Process Concept Process - a program in execu2on process execu2on proceeds in a sequen2al fashion Mul2programming: several programs apparently execu2ng concurrently. Process States e.g. new, running, ready, wai2ng, terminated. 3 3

CPU Switch From Process to Process C structure task_struct 4 4

Process Crea2on Processes are created and deleted dynamically Process which creates another process is called a parent process; the created process is called a child process. Result is a tree of processes e.g. UNIX - processes have dependencies and form a hierarchy. Resources required when crea2ng process CPU 2me, files, memory, I/O devices etc. login pid = 8415 init pid = 1 kthreadd pid = 2 sshd pid = 3028 cid = fork(); if (cid < 0) { /* error occurred */ fprin^(stderr, "Fork Failed\n"); return 1; else if (cid == 0) { /* child process */ execlp("/bin/ls","ls",null); else { /* parent process, will wait for child to complete */ wait(null); bash pid = 8416 khelper pid = 6 pdflush pid = 200 sshd pid = 3610 ps pid = 9298 emacs pid = 9204 tcsch pid = 4005 5 5

Threads A thread (or lightweight process) basic unit of CPU u2liza2on; it consists of: program counter, register set and stack space A thread shares the following with peer threads: code sec2on, data sec2on and OS resources (open files, signals) Collec2vely called a task. Thread support in modern systems User threads vs. kernel threads, lightweight processes 1-1, many-1 and many-many mapping Implicit Threading (e.g. OpenMP) Hardware support in newer processors 6 6

Producer-Consumer Problem Paradigm for coopera2ng processes; producer process produces informa2on that is consumed by a consumer process. We need buffer of items that can be filled by producer and emp2ed by consumer. Unbounded-buffer Bounded-buffer Producer and Consumer must synchronize. item next_produced; while (true) { /* produce an item in next produced */ while (((in + 1) % BUFFER_SIZE) == out) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; Out In 7 0 1 2 3 4 5 6 7 7

Interprocess Communica2on (IPC) Mechanism for processes to communicate and synchronize their ac2ons. Via shared memory Pipes Sockets Via Messaging system - processes communicate without resor2ng to shared variables. int fd[2]; create the pipe: if (pipe(fd) == -1) { fprin^(stderr,"pipe failed"); return 1; fork a child process: pid = fork(); parent process: /* close the unused end of the pipe */ close(fd[read_end]); /* write to the pipe */ write(fd[write_end], write_msg, strlen(write_msg)+1); /* close the write end of the pipe */ close(fd[write_end]); 8 8

CPU Scheduling CPU u;liza;on keep the CPU as busy as possible: Maximize Throughput # of processes that complete their execu2on per 2me unit: Maximize Turnaround ;me 2me to execute a process from submission to comple2on: Minimize Wai;ng ;me amount of 2me a process has been wai2ng in the ready queue: Minimize Response ;me 2me it takes from when a request was submived un2l the first response is produced, not output (for 2me-sharing environment): Minimize 9 9

Scheduling Policies FCFS (First Come First Serve) Process that requests the CPU FIRST is allocated the CPU FIRST. SJF (Shortest Job First) Associate with each process the length of its next CPU burst. Use these lengths to schedule the process with the shortest 2me. Shortest-remaining-2me-first (preemp2ve SJF) A process preempted by an arriving process with shorter remaining 2me Priority A priority value (integer) is associated with each process. CPU allocated to process with highest priority. Round Robin Each process gets a small unit of CPU 2me Mul2Level ready queue par22oned into separate queues Varia2on: Mul2level Feedback queues: priority lower or raised based on history Other 10 10

All arrive at 2me 0. SJF scheduling chart Example of SJF ProcessArriva l TimeBurst Time P 1 0.0 6 P 2 2.0 8 P 3 4.0 7 P 4 5.0 3 P 4 P 1 P 3 P 2 0 3 9 16 24 Average wai2ng 2me for P 1,P 2,P 3,P 4 = (3 + 16 + 9 + 0) / 4 = 7 11

Determining Length of Next CPU Burst Can be done by using the length of previous CPU bursts, using exponen:al averaging 1. t n = actual length of n 2. τ n+ 1 3. α, 0 α 1 CPU burst = predicted value for the next CPU burst 4. Define : τ n= 1 = α tn + 1 α τ n Commonly, α set to ½ th ( ). 12 τ i 10 8 t i 6 4 2 time CPU burst (t i ) 6 4 6 4 13 13 13 "guess" (τ i ) 10 8 6 6 5 9 11 12 12

Example of RR with Time Quantum = 4 Process Burst Time P 1 24 P 2 3 P 3 3 Arrive a 2me 0 in order P1, P2, P3: The Ganv chart is: P P 2 P 3 P 1 P 1 P 1 P P 1 1 1 13 0 4 7 10 14 18 22 26 30 Wai2ng 2mes: P1:10-4 =6, P2:4, P3:7, average 17/3 = 5.66 units Typically, higher average turnaround than SJF, but bever response q should be large compared to context switch 2me q usually 10ms to 100ms, context switch overhead < 1% Response 2me: Arrival to beginning of execu2on: P2: 4 Turnaround 2me: Arrival to finish of execu2on: P2: 7

Mul2ple-Processor Scheduling CPU scheduling more complex when mul2ple CPUs are available. Assume Homogeneous processors within a mul2processor Asymmetric mul;processing only one processor accesses the system data structures, allevia2ng the need for data sharing Symmetric mul;processing (SMP) each processor is self-scheduling, all processes in common ready queue, or each has its own private queue of ready processes Currently, most common Processor affinity process has affinity for processor on which it is currently running because of info in cache sop affinity: try but no guarantee hard affinity can specify processor sets 14

Mul2threaded Mul2core System This is temporal mul2threading. Simultaneous mul2threading allows threads to computer in parallel 15

Consumer-producer problem Producer while (true) { /* produce an item*/ while (counter == BUFFER_SIZE) ; /* do nothing */ buffer[in] = next_produced; in = (in + 1) % BUFFER_SIZE; counter++; Consumer while (true) { while (counter == 0); /* do nothing */ next_consumed = buffer[out]; out = (out + 1) % BUFFER_SIZ counter--; /* consume the item in next consumed */ They run concurrently (or in parallel), and are subject to context switches at unpredictable 2mes. 16 16

Race Condi2on counter++ could be compiled as register1 = counter register1 = register1 + 1 counter = register1 counter-- could be compiled as register2 = counter register2 = register2-1 counter = register2 They run concurrently, and are subject to context switches at unpredictable 2mes. Consider this execu2on interleaving with count = 5 ini2ally: S0: producer execute register1 = counter {register1 = 5 S1: producer execute register1 = register1 + 1 {register1 = 6 S2: consumer execute register2 = counter {register2 = 5 S3: consumer execute register2 = register2 1 {register2 = 4 S4: producer execute counter = register1 {counter = 6 S5: consumer execute counter = register2 {counter = 4 17 Overwrites!

The Cri2cal Sec2on Problem Requirements Mutual Exclusion Progress Bounded Wai2ng Solu2on to the cri2cal sec2on problem do { acquire lock critical section release lock remainder section while (TRUE); 18 18

Peterson s Algorithm for Process P i do { flag[i] = true; turn = j; while (flag[j] && turn = = j); /*Wait*/ critical section flag[i] = false; while (true); remainder section Being nice! The variable turn indicates whose turn it is to enter the cri2cal sec2on flag[i] = true implies that process P i is ready! Proofs for Mutual Exclusion, Progress, Bounded Wait 19

Solu2on using test_and_set() Shared Boolean variable lock, ini2alized to FALSE Solu2on: do { while (test_and_set(&lock)) ; /* do nothing */ /* critical section */.. lock = false; /* remainder section */.. while (true); 20

Bounded-wai2ng Mutual Exclusion with test_and_set For process i: do { waiting[i] = true; key = true; while (waiting[i] && key) key = test_and_set(&lock); waiting[i] = false; /* critical section */ j = (i + 1) % n; while ((j!= i) &&!waiting[j]) j = (j + 1) % n; if (j == i) lock = false; else waiting[j] = false; /* remainder section */ while (true); Shared Data structures initialized to FALSE boolean waiting[n]; boolean lock; The entry sec2on for process i : First process to execute TestAndSet will find key == false ; ENTER cri2cal sec2on, EVERYONE else must wait The exit sec2on for process i: Part I: Finding a suitable wai2ng process j and enable it to get through the while loop, or if thre is no suitable process, make lock FALSE. 21

Mutex Locks Protect a cri2cal sec2on by first acquire() a lock then release() the lock Boolean indica2ng if lock is available or not Calls to acquire() and release() must be atomic Usually implemented via hardware atomic instruc2ons But this solu2on requires busy wai;ng This lock therefore called a spinlock Usage do { acquire lock critical section release lock remainder section while (true); acquire() { while (!available) ; /* busy wait */ release() { available = true; 22

Semaphore Synchroniza2on tool that provides more sophis2cated ways (than Mutex locks) for process to synchronize their ac2vi2es. Semaphore S integer variable Can only be accessed via two indivisible (atomic) opera2ons wait() and signal() Originally called P() and V() Defini2on of the wait() operation wait(s) { while (S <= 0) ; // busy wait S--; Defini2on of the signal() operation signal(s) { S++; 23

Wait(S) and Signal (S) Process 0 Process 1 Semaphore S Wait(S) Cri2cal sec2on Signal (S) S =1 S =0 S =1 S =0 Locked by Process 1 Wait (S) Busy wai2ng Gets lock, S- - Cri2cal sec2on Signal (S) S =1 24

Readers-Writers Problem (Cont.) The structure of a reader process do { wait(mutex); read_count++; if (read_count == 1) wait(rw_mutex); signal(mutex);... /* reading is performed */... wait(mutex); read count--; if (read_count == 0) signal(rw_mutex); signal(mutex); while (true); mutex for mutual exclusion to readcount When: writer in cri2cal sec2on and if n readers wai2ng 1 is queued on rw_mutex (n-1) queued on mutex The structure of a writer process do { wait(rw_mutex);... /* writing is performed */... signal(rw_mutex); while (true); 25

Implementa2on with no Busy wai2ng (Coun2ng Sema) wait(semaphore *S) { S->value--; if (S->value < 0) { add this process to S->list; block(); signal(semaphore *S) { S->value++; if (S->value <= 0) { remove a process P from S->list; wakeup(p); typedef struct{ int value; struct process *list; semaphore; 26

Monitors and Condi2on Variables monitor monitor-name { // shared variable declarations procedure P1 ( ) {. procedure Pn ( ) { Initialization code ( ) { The condition construct condition x, y; Two opera2ons are allowed on a condi2on variable: x.wait() a process that invokes the opera2on is suspended un2l x.signal() x.signal() resumes one of processes (if any) that invoked x.wait() If no x.wait() on the variable, then it has no effect on the variable. Signal is lost. 27

The pickup() and putdown() opera2ons monitor DiningPhilosophers { enum { THINKING, HUNGRY, EATING state [5] ; condition self [5]; void pickup (int i) { state[i] = HUNGRY; test(i); //on next slide if (state[i]!= EATING) self[i].wait; void putdown (int i) { state[i] = THINKING; // test left and right neighbors test((i + 4) % 5); test((i + 1) % 5); void test (int i) { if ((state[(i + 4) % 5]!= EATING) && (state[i] == HUNGRY) && (state[(i + 1) % 5]!= EATING) ) { state[i] = EATING ; self[i].signal () ; initialization_code() { for (int i = 0; i < 5; i++) state[i] = THINKING; 28