CPS110: Threads review and wrap up

Slides:



Advertisements
Similar presentations
Operating Systems ECE344 Midterm review Ding Yuan
Advertisements

More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
Cpr E 308 Spring 2004 Recap for Midterm Introductory Material What belongs in the OS, what doesn’t? Basic Understanding of Hardware, Memory Hierarchy.
Review: Chapters 1 – Chapter 1: OS is a layer between user and hardware to make life easier for user and use hardware efficiently Control program.
1 CS318 Project #3 Preemptive Kernel. 2 Continuing from Project 2 Project 2 involved: Context Switch Stack Manipulation Saving State Moving between threads,
Threads vs. Processes April 7, 2000 Instructor: Gary Kimura Slides courtesy of Hank Levy.
CPS110: Implementing threads/locks on a uni-processor Landon Cox.
Threads CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
Scheduler Activations Jeff Chase. Threads in a Process Threads are useful at user-level – Parallelism, hide I/O latency, interactivity Option A (early.
CSE 451: Operating Systems Autumn 2013 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
1 Processes and Threads Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
COP 4600 Operating Systems Spring 2011 Dan C. Marinescu Office: HEC 304 Office hours: Tu-Th 5:00-6:00 PM.
Welcome to the World of Nachos CPS 110 Spring 2004 Discussion Session 1.
Protection and the Kernel: Mode, Space, and Context.
CS 153 Design of Operating Systems Spring 2015
CSC 501 Lecture 2: Processes. Process Process is a running program a program in execution an “instantiation” of a program Program is a bunch of instructions.
Threads and Concurrency. A First Look at Some Key Concepts kernel The software component that controls the hardware directly, and implements the core.
Implementing Synchronization. Synchronization 101 Synchronization constrains the set of possible interleavings: Threads “agree” to stay out of each other’s.
Chapter 1 Process and Thread. 1.2 process The address space of a program – Text – Code – Stack – Heap A set of registers – PC – SP Other resources – Files.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Thread Scheduling.
Race Conditions Defined 1. Every data structure defines invariant conditions. defines the space of possible legal states of the structure defines what.
Copyright ©: University of Illinois CS 241 Staff1 Threads Systems Concepts.
CPS110: Implementing threads Landon Cox. Recap and looking ahead Hardware OS Applications Where we’ve been Where we’re going.
CSE 451: Operating Systems Winter 2015 Module 5 1 / 2 User-Level Threads & Scheduler Activations Mark Zbikowski 476 Allen Center.
Introduction to Operating Systems and Concurrency.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Processes, Threads, and Process States. Programs and Processes  Program: an executable file (before/after compilation)  Process: an instance of a program.
CPS110: Threads review and wrap up Landon Cox February 11, 2009.
Administrivia Nachos guide and Lab #1 are on the web. Form project teams of 2-3. Lab #1 due February 5. Synchronization.
CSE 153 Design of Operating Systems Winter 2015 Midterm Review.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
CPS110: Implementing threads on a uni-processor Landon Cox January 29, 2008.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
Scheduler activations Landon Cox March 23, What is a process? Informal A program in execution Running code + things it can read/write Process ≠
Threads prepared and instructed by Shmuel Wimer Eng. Faculty, Bar-Ilan University 1July 2016Processes.
Tutorial 2: Homework 1 and Project 1
CS 3214 Computer Systems Lecture 9 Godmar Back.
Introduction to Kernel
Multi-programming in THE
Process concept.
CS 6560: Operating Systems Design
CS703 – Advanced Operating Systems
Scheduler activations
Semaphores and Condition Variables
Operating Systems ECE344 Lecture 4: Threads Ding Yuan.
More Threads and Synchronization
Lecture 10: Threads Implementation
COP 4600 Operating Systems Spring 2011
CSE 451: Operating Systems Spring 2012 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
Jonathan Walpole Computer Science Portland State University
Thread Implementation Issues
COT 5611 Operating Systems Design Principles Spring 2012
Threads and Concurrency
Threads Chapter 4.
Implementing Mutual Exclusion
Threads Chapter 5 2/17/2019 B.Ramamurthy.
Threads Chapter 5 2/23/2019 B.Ramamurthy.
Still Chapter 2 (Based on Silberchatz’s text and Nachos Roadmap.)
Implementing Mutual Exclusion
February 5, 2004 Adrienne Noble
Lecture 10: Threads Implementation
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
Implementing Processes, Threads, and Resources
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
Threads vs. Processes Hank Levy 1.
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
CS703 – Advanced Operating Systems
CSE 153 Design of Operating Systems Winter 2019
Presentation transcript:

CPS110: Threads review and wrap up Landon Cox February 12, 2008

Virtual/physical interfaces Applications SW atomic operations OS HW atomic operations Hardware

Classic synchronization problem Sofa capacity = 4 Standing room Customer room capacity = 9

Barbershop Enter room Sit on sofa Sit in chair Wake up barber Customer () { lock.acquire (); while (numInRoom == 9) roomCV.wait (lock); numInRoom++; while (numOnSofa == 4) sofaCV.wait (lock); numOnSofa++; while (numInChair == 3) chairCV.wait (lock); numInChair++; numOnSofa--; sofaCV.signal (lock); customerCV.signal (lock); cutCV.wait (lock); numInChair--; chairCV.signal (lock); numInRoom--; roomCV.signal (lock); lock.release (); } lock; roomCV; numInRoom=0; sofaCV; numOnSofa=0; chairCV; numInChair=0; customerCV; cutCV; Enter room Sit on sofa Sit in chair Wake up barber Wait for cut to finish Leave the shop

Barbershop Customer () { lock.acquire (); while (numInRoom == 9) roomCV.wait (lock); numInRoom++; while (numOnSofa == 4) sofaCV.wait (lock); numOnSofa++; while (numInChair == 3) chairCV.wait (lock); numInChair++; numOnSofa--; sofaCV.signal (lock); customerCV.signal (lock); cutCV.wait (lock); numInChair--; chairCV.signal (lock); numInRoom--; roomCV.signal (lock); lock.release (); } Barber () { lock.acquire (); while (1) { while (numInChair == 0) customerCV.wait (lock); cutHair (); cutCV.signal (); } lock.release ();

Barbershop with semaphores Customer () { room.down () // enter room sofa.down () // sit on sofa chair.down () // sit on chair sofa.up () customer.up () cut.down () // leave chair chair.up () // leave room room.up () } Semaphore room = 9, sofa = 4, chair = 3, customer = 0, cut = 0; Barber () { while (1) { customer.down() // cut hair cut.up () } Is anything weird here?

Course administration Project 1 Due in ~1.5 weeks Should be done with disk scheduler Should be knee-deep in thread library Extra office hours Will post/announce on Thursday Any questions?

Course administration Looking ahead Wrapping up synchronization today Address spaces up next Mid-term exam In two weeks (February 26) Rest of lecture: mini-review of threads

Program with two threads address space “on deck” and ready to run common runtime x program code library running thread data R0 CPU Rn y PC x stack SP y registers stack high “memory”

Thread context switch program switch in switch out address space common runtime x program code library data R0 1. save registers CPU Rn y PC x stack SP y registers 2. load registers stack high “memory”

char stack[StackSize] Portrait of a thread t = new Thread(name); t->Fork(MyFunc, arg); currentThread->Sleep(); currentThread->Yield(); “fencepost” Thread* t low unused region 0xdeadbeef machine state name/status, etc. Stack high stack top thread object or thread control block char stack[StackSize]

/* * Save context of the calling thread (old), restore registers of * the next thread to run (new), and return in context of new. */ switch/MIPS (old, new) { old->stackTop = SP; save RA in old->MachineState[PC]; save callee registers in old->MachineState restore callee registers from new->MachineState RA = new->MachineState[PC]; SP = new->stackTop; return (to RA) }

Ex: SwitchContext on MIPS Save current stack pointer and caller’s return address in old thread object. /* * Save context of the calling thread (old), restore registers of * the next thread to run (new), and return in context of new. */ switch/MIPS (old, new) { old->stackTop = SP; save RA in old->MachineState[PC]; save callee registers in old->MachineState restore callee registers from new->MachineState RA = new->MachineState[PC]; SP = new->stackTop; return (to RA) } Caller-saved registers (if needed) are already saved on the thread’s stack. Caller-saved regs restored automatically on return. Switch off of old stack and back to new stack. Return to procedure that called switch in new thread.

Thread States and Transitions running Thread::Yield (voluntary or involuntary) Thread::Sleep (voluntary) Scheduler::Run blocked ready “wakeup”

Threads vs. Processes A process is an abstraction “Independent executing program” Includes at least one “thread of control” Also has a private address space (VAS) Requires OS kernel support To be covered in upcoming lectures data data

Threads vs. Processes Threads may share an address space Have “context” just like vanilla processes Exist within some process VAS Processes may be “multithreaded” Key difference thread context switch vs. process context switch Project 2: manage process context switches data data

Play analogy What is a process? Another performance! Threads Threads Address space Address space Another performance!

Locks Ensure mutual exclusion in critical sections. A lock is an object, a data item in memory. Threads pair calls to Acquire and Release. Acquire before entering a critical section. Release after leaving a critical section. Between Acquire/Release, the lock is held. Acquire doesn’t return until previous holder releases. Waiting locks can spin (a spinlock) or block (a mutex). A A R R

Portrait of a Lock in Motion Who can explain this figure? R A A R

Dining philosophers Who can explain this figure? X 2 1 Y A1 A2 R2 R1 ??? 2 1 A2 Y

Kernel-supported threads Most newer OS kernels have kernel-supported threads. Thread model and scheduling defined by OS NT, advanced Unix, etc. Linux: threads are “lightweight processes” Kernel scheduler (not a library) decides which thread to run next. New kernel system calls, e.g.: thread_fork thread_exit thread_block thread_alert etc... data Threads can block independently in kernel system calls. Threads must enter the kernel to block: no blocking in user space

User-level threads Can also implement user-level threads in a library. No special support needed from the kernel (use any Unix) Thread creation and context switch are fast (no syscall) Defines its own thread model and scheduling policies Kernel only sees a single process Project 1t readyList data while(1) { t = get next ready thread; scheduler->Run(t); }

Kernel threads What is “kernel mode?” Mode the OS executes in PC SP PC SP PC SP PC SP … … … … User mode Kernel mode What is “kernel mode?” Mode the OS executes in Heightened privileges Will cover later Scheduler

User threads Thread Thread Thread Thread PC SP PC SP PC SP PC SP … … … Sched User mode Kernel mode Kernel mode Scheduler

Kernel vs user tradeoffs Which do you expect to perform better? User-threads should perform better Synchronization functions are just a function call Attractive in low-contention scenarios Don’t want to kernel trap on every lock acquire What is the danger of user-level threads? If a user thread blocks, entire process blocks May be hard to take advantage of multiple CPUs

Possible solution Asynchronous process-kernel interactions Process never blocks in kernel Library sleeps thread before entering kernel If IO, etc ready, library handles interrupt Restarts thread with correct syscall results Still not ideal for multi-core Idea: want to create kernel thread for each core Let user library manage multiple kernel threads

Performance Comparison Comparing user-level threads, kernel threads, and processes. Operation FastThreads Topaz Threads Ultrix Processes Null fork 34 948 11300 Signal-wait 37 441 1840 Procedure call takes 7 microseconds. Kernel trap takes 19 microseconds. Maybe kernel trap is not so significant.

What’s next We now understand threads Each has it a private stack, registers, TCB Next, we’ll try to understand processes Address spaces differentiate processes Address spaces are tied to memory, not CPU Can think of as a private namespace