CS3210: Coordination. Tim Andersen

Similar documents
Chapter 5. Scheduling. Multiplexing. Code: Context switching

FINE-GRAINED SYNCHRONIZATION. Operating Systems Engineering. Sleep & Wakeup [chapter #5] 15-Jun-14. in the previous lecture.

Problem Set 2. CS347: Operating Systems

Processes (Intro) Yannis Smaragdakis, U. Athens

CS3210: Isolation Mechanisms

143A: Principles of Operating Systems. Lecture 11: Synchronization. Anton Burtsev November, 2018

CS238P: Operating Systems. Lecture 12: Synchronization. Anton Burtsev March, 2018

3. Process Management in xv6

Problem Set: xv6. Lecture Notes on Operating Systems. 1. Consider the following lines of code in a program running on xv6.

Building Concurrency Primitives

Operating Systems Synchronization and Signals

ICS143A: Principles of Operating Systems. Midterm recap, sample questions. Anton Burtsev February, 2017

Changes made in this version not seen in first lecture:

4. The Abstraction: The Process

Intro to Threads. Two approaches to concurrency. Threaded multifinger: - Asynchronous I/O (lab) - Threads (today s lecture)

CS3210: Virtual memory applications

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs

CS3210: Processes and switching 1. Taesoo Kim

The Process Abstraction. CMPU 334 Operating Systems Jason Waterman

Processes and Threads

Chapter 6. Buffer cache. Code: Data structures

Operating Systems, Assignment 2 Threads and Synchronization

1 Programs and Processes

ECE 391 Exam 1 Review Session - Spring Brought to you by HKN

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Hank Levy 412 Sieg Hall

Misc. Notes. In BVT, switch from i j only if E j E i C/w i. In BVT, Google is example of W better then L. For lab, recall PDE and PTE bits get ANDed

6.033 Computer System Engineering

Processes. q Process concept q Process model and implementation q Multiprocessing once again q Next Time: Scheduling

Stack -- Memory which holds register contents. Will keep the EIP of the next address after the call

Quiz I Solutions MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Department of Electrical Engineering and Computer Science

MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I

Lecture 4 CIS 341: COMPILERS

by Marina Cholakyan, Hyduke Noshadi, Sepehr Sahba and Young Cha

Administrivia. p. 1/20

Precept 2: Non-preemptive Scheduler. COS 318: Fall 2018

Section 4: Threads CS162. September 15, Warmup Hello World Vocabulary 2

Processes. Chester Rebeiro IIT Madras

Lecture 5: Synchronization w/locks

CMSC 412 Project #3 Threads & Synchronization Due March 17 th, 2017, at 5:00pm

Synchronization COMPSCI 386

LAB 2: PROCESS SYNCHRONIZATION IN XV6

CS3210: Multiprocessors and Locking

Function Calls COS 217. Reading: Chapter 4 of Programming From the Ground Up (available online from the course Web site)

Concurrency: Signaling and Condition Variables

[537] Locks. Tyler Harter

Processes. Today. Next Time. Process concept Process model Implementing processes Multiprocessing once again. Scheduling processes

Synchronization I. Jo, Heeseung

CS 537 Lecture 2 - Processes

Locks. Dongkun Shin, SKKU

CS 153 Design of Operating Systems Winter 2016

[537] Locks and Condition Variables. Tyler Harter

Native POSIX Thread Library (NPTL) CSE 506 Don Porter

CS5460/6460: Operating Systems. Lecture 9: First process. Anton Burtsev January, 2014

MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I Solutions. Mean 70.5 Median 72 Standard deviation 15.8 Kurtosis -0.

CS 318 Principles of Operating Systems

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

CS 31: Introduction to Computer Systems : Threads & Synchronization April 16-18, 2019

Project 2: Signals. Consult the submit server for deadline date and time

CS3210: Processes and Switching

Changes made in this version not seen in first lecture:

CS3210: Virtual memory applications. Taesoo Kim

Today s Topics. u Thread implementation. l Non-preemptive versus preemptive threads. l Kernel vs. user threads

x86 architecture et similia

CS 318 Principles of Operating Systems

Today s Topics. u Thread implementation. l Non-preemptive versus preemptive threads. l Kernel vs. user threads

Processes Prof. James L. Frankel Harvard University. Version of 6:16 PM 10-Feb-2017 Copyright 2017, 2015 James L. Frankel. All rights reserved.

X86 Stack Calling Function POV

x86 assembly CS449 Fall 2017

Lecture #7: Implementing Mutual Exclusion

Lecture 9: Multiprocessor OSs & Synchronization. CSC 469H1F Fall 2006 Angela Demke Brown

Synchroniza+on. Today: Implementa+on issues

CPS 310 first midterm exam, 10/6/2014

CPSC/ECE 3220 Fall 2017 Exam Give the definition (note: not the roles) for an operating system as stated in the textbook. (2 pts.

10/17/ Gribble, Lazowska, Levy, Zahorjan 2. 10/17/ Gribble, Lazowska, Levy, Zahorjan 4

Reminder from last time

CS3210: Crash consistency

CSC 2400: Computer Systems. Using the Stack for Function Calls

Project 3 Improved Process Management

Synchronization 1. Synchronization

Mutex Implementation

Section 4: Threads and Context Switching

Chapter 6: Process Synchronization

MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I

Process & Thread Management II. Queues. Sleep() and Sleep Queues CIS 657

Process & Thread Management II CIS 657

CS 550 Operating Systems Spring Concurrency Semaphores, Condition Variables, Producer Consumer Problem

Synchronization. CS61, Lecture 18. Prof. Stephen Chong November 3, 2011

SYSTEM CALL IMPLEMENTATION. CS124 Operating Systems Fall , Lecture 14

Program Exploitation Intro

Implementing Threads. Operating Systems In Depth II 1 Copyright 2018 Thomas W. Doeppner. All rights reserved.

Concurrency, Thread. Dongkun Shin, SKKU

Processes & Threads. Today. Next Time. ! Process concept! Process model! Implementing processes! Multiprocessing once again. ! More of the same J

CS3210: File Systems Tim Andersen

Processes. Johan Montelius KTH

Assembly Language Programming: Procedures. EECE416 uc. Charles Kim Howard University. Fall

Review: Thread package API

A process. the stack

CMSC421: Principles of Operating Systems

CSE 153 Design of Operating Systems Fall 18

Synchronization I. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

Transcription:

1 CS3210: Coordination Tim Andersen

2 Administrivia Lab5 out, due November 21st Demo day: 8 min for demo, 2 min for Q&A Final project (write up): December 2nd

3 Today's plan Context switching (i.e., swtch and sched) in detail Sequence coordination xv6: sleep & wakeup Challenges Lost wakeup problem Signals

4 Multiplexing Sleep and wakeup mechanism switches when a process Waits for a device or pipe I/O to complete Waits for a child to exit Waits in the sleep system call xv6 periodically forces a switch Creates the illusion that each process has its own CPU

5 Implementation challenges Q: How to switch from one process to another? A: Context switching Q: How to make context switching transparent? A: Timer interrupts Q: How to switch among processes running concurrently? A: Locking Q: How to coordinate processes? A: Sleep on events (e.g., pipe, child exit)

6 Two kinds of context switch 1. From a process's kernel thread to CPU scheduler thread 2. From the scheduler thread to a process's kernel thread. xv6 never directly switches from user space to user space user kernel transition (system call or interrupt) context switch to scheduler context switch to new process's kernel thread trap return

Big picture: switching 7

8 Context switching Every xv6 process has its own kernel stack and register set Every CPU has its own scheduler thread Switching from one thread to another Save and load CPU registers, including %esp, %eip.

9 swtch void swtch(struct context**, struct context*); Doesn't know about threads just saves and loads sets of registers called contexts When time to give up CPU, kernel thread calls swtch to save itself and return to scheduler context Context is a struct context*, stored on the kernel stack CPU pushed onto stack and saves stack pointer to *old Copies new to %esp, pops previous registers, and returns

10 Switching overview: CPU perspective CPU1 schedule() CPU0 kstack (entry.s) CPU1 kstack (main.c) shared proc [0] [1] shell proc[1].kstack (proc.h) cat proc[2].kstack (proc.h) CPU0 ❶ ptable.lock Q1: ring? swtch() trapret ❷ Q2: ring? esp? trap ❸

11 yield At the end of each interrupt, trap can call yield yield sched swtch Switches from proc->context to cpu->scheduler

12 swtch: Detailed Look Loads its arguments off the stack into %eax and %edx before it loses its arguments when it changes %esp Only callee save registers saved %ebp, %ebx, %esi, %ebp, and %esp First four pushed, %esp saved as *old %eip was saved by the call instruction and is just above %ebp Moves pointer to new context into %esp Inverts sequence of steps to load context

13 Switching overview: CPU perspective CPU0 kstack (entry.s) CPU1 kstack (main.c) shared proc [0] [1] shell proc[1].kstack (proc.h) cat proc[2].kstack (proc.h) CPU0 ❹ ❸ ptable.lock yield() schedule() swtch() ❺

14 Show xv6 Code swtch(), scheduler(), sched() about ptable.lock

15 Scheduling Process giving up the CPU must aquire ptable.lock release any other locks update its own state (e.g., RUNNABLE, SLEEPING) call sched yield, sleep, and exit all do these steps

16 DEMO: sched br sched commands p cpus[cpunum()].proc.pid c end

17 ptable.lock Held across calls to swtch Caller holding lock passes control to switched to code Needed because process state and context must be kept invariant across swtch Without lock, a different CPU might try to run a process after RUNNABLE but before kernel stack switch. Result is two CPUs with same stack.

18 sched and scheduler Kernel thread always gives up in sched and switches to same location in scheduler Almost always switches to a process in sched. Thread switches follow a simple pattern between sched and scheduler Coroutines Exception is forkret when process is first scheduled

19 Scheduler Loops over process table looking for RUNNABLE processes Finding one, sets current per CPU process to proc Switches page table with switchuvm, marks as RUNNING, and calls swtch

20 Sequence coordination How to arrange for threads to wait for each other to do e.g., wait for disk interrupt to complete e.g., wait for pipe readers to make space in pipe e.g., wait for child to exit e.g., wait for block to use

21 Producer and Consumer Queue Queue allows one process to send a nonzero pointer to another process For only one sender and one receiver on different CPUs. Send loops until queue is empty then puts pointer p in the queue Recv loops until the queue is non empty and takes the pointer out Both modify q->ptr, but send only writes the pointer when zero Recv only writes when nonzero, so no lost updates

22 Strawman solution: spin 01 struct q { void *ptr; }; 02 03 void* send(struct q *q, void *p) { 04 while(q->ptr!= 0) 05 ; 06 q->ptr = p; 07 } 08 09 void* recv(struct q *q) { 10 void *p; 11 while((p = q->ptr) == 0) 12 ; 13 q->ptr = 0; 14 return p; 15 }

23 Strawman solution: spin Q: cpu0 send(), cpu1 recv()? Q: cpu0 send(), cpu1 send()? Q: cpu0 recv(), cpu1 send()? Q: cpu0 recv(), cpu1 recv()? Q: problem?

24 Better solution: primitives for coordination Sleep & wakeup (xv6) Condition variables (e.g., pthread_cond) Barriers (next tutorial)

25 Sleep & wakeup sleep(chan) sleeps on a "channel", an address to name the condition we are sleeping on wakeup(chan) wakeup wakes up all threads sleeping on chan this may wake up more than one thread

26 Attempt 1: sleep & wakeup 01 void* send(struct q *q, void *p) { 02 while(q->ptr!= 0) 03 ; 04 q->ptr = p; 05 wakeup(q); /* Q? */ 06 } 07 08 void* recv(struct q *q) { 09 void *p; 10 while((p = q->ptr) == 0) 11 sleep(q); /* Q? */ 12 q->ptr = 0; 13 return p; 14 }

27 Strawman solution: spin Q: cpu0 send(), cpu1 recv()? Q: cpu0 send(), cpu1 send()? Q: cpu0 recv(), cpu1 send()? Q: cpu0 recv(), cpu1 recv()? Q: problem? (hint: concurrently run while in send/recv)

Lost wakeup problem 28

29 Attempt1: fixing the lost wakeup problem Q: how to atomically run the code (checking and sleeping)? 10 while((p = q->ptr) == 0) 11 sleep(q);

30 Attempt1: fixing the lost wakeup problem Let's use a spinlock struct q { struct spinlock lock; void *ptr; };

31 Attempt1: fixing the lost wakeup problem 01 void* send(struct q *q, void *p) { 02 acquire(&q->lock); 03 while(q->ptr!= 0) 04 ; 05 q->ptr = p; 06 wakeup(q); 07 release(&q->lock); 08 } 09 10 void* recv(struct q *q) { 11 void *p; 12 acquire(&q->lock); 13 while((p = q->ptr) == 0) 14 sleep(q); 15 q->ptr = 0; 16 release(&q->lock); 17 return p; 18 }

32 Problems? Q: cpu0 send(), cpu1 recv()? Q: cpu0 send(), cpu1 send()? Q: cpu0 recv(), cpu1 send()? Q: cpu0 recv(), cpu1 recv()?

33 Attempt2: releasing the lock when sleeping 01 void* send(struct q *q, void *p) { 02 acquire(&q->lock); 03 while(q->ptr!= 0) 04 ; 05 q->ptr = p; 06 wakeup(q); 07 release(&q->lock); 08 } 09 10 void* recv(struct q *q) { 11 void *p; 12 acquire(&q->lock); 13 while((p = q->ptr) == 0) 14 sleep(q, &q->lock); 15 q->ptr = 0; 16 release(&q->lock); 17 return p; 18 }

34 Problems? Q: cpu0 send(), cpu1 recv()? Q: cpu0 send(), cpu1 send()? Q: cpu0 recv(), cpu1 send()? Q: cpu0 recv(), cpu1 recv()? We need a similar treatment for send() (i.e., sleep())

35 Code sleep(), wakeup() about: ptable.lock

36 Summary: sleep takes a lock as argument Sleeper and wakeup acquires locks for shared data structure sleep() holds the lock until after it has ptable.lock Once it has ptable.lock, no wakeup can come in before it sets state to sleeping no lost wakeup problem Requires that sleep takes a lock argument!

37 Case study: ide (blockio) Device I/O is too slow to just spin (wait) for its competition bread(b) iderw(b) it waits (sleep) until the requests block is ready trap() ideintr() it notifies (wakeup) the waiter

38 Example: iderw code: iderw() (sleeper), ideintr() (wakeup) Q: wakeup cannot get lock until sleeper is already to at sleep, why a loop around sleep? 01 // Wait for request to finish. 02 while((b flags & (B_VALID B_DIRTY))!= B_VALID){ 03 sleep(b, &idelock); 04 }

39 Another example: pipe What is the race if sleep didn't take p lock as argument?

40 Many primitives in literature to solve lost wakeup problem Counting wakeup&sleep calls in semaphores Pass locks as an extra argument in condition variables (as in sleep)

41 References Intel Manual UW CSE 451 OSPP MIT 6.828 Wikipedia The Internet