CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 9, 2009 Prof. John Kubiatowicz

Slides:



Advertisements
Similar presentations
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.
Advertisements

Concurrency: Threads, Address Spaces, and Processes Sarah Diesburg Operating Systems COP 4610.
Why Concurrency? Allows multiple applications to run at the same time  Analogy: juggling.
CS194-3/CS16x Introduction to Systems Lecture 5 Concurrency, Processes and threads, Overview of ACID September 12, 2007 Prof. Anthony D. Joseph
CMPT 300: Operating Systems I Dr. Mohamed Hefeeda
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 12, 2005 Prof. John Kubiatowicz
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Dr. Mohamed Hefeeda.
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching January 30, 2006 Prof. Anthony D. Joseph
Page 1 Processes and Threads Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
CS162 Operating Systems and Systems Programming Lecture 3 Concurrency: Processes, Threads, and Address Spaces September 7, 2005 Prof. John Kubiatowicz.
OS Spring’03 Introduction Operating Systems Spring 2003.
CS162 Operating Systems and Systems Programming Lecture 3 Concurrency: Processes, Threads, and Address Spaces September 8, 2008 Prof. John Kubiatowicz.
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 10, 2008 Prof. John Kubiatowicz
CPS110: Implementing threads/locks on a uni-processor Landon Cox.
1 Process Description and Control Chapter 3 = Why process? = What is a process? = How to represent processes? = How to control processes?
Threads CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
Process Description and Control A process is sometimes called a task, it is a program in execution.
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 11, 2006 Prof. John Kubiatowicz
Processes in Unix, Linux, and Windows CS-502 Fall Processes in Unix, Linux, and Windows CS502 Operating Systems (Slides include materials from Operating.
Operating Systems CSE 411 CPU Management Sept Lecture 11 Instructor: Bhuvan Urgaonkar.
Protection and the Kernel: Mode, Space, and Context.
Thread. A basic unit of CPU utilization. It comprises a thread ID, a program counter, a register set, and a stack. It is a single sequential flow of control.
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 Many software packages are multi-threaded Web browser: one thread display images, another thread retrieves data from the network Word processor:
CS162 Operating Systems and Systems Programming Lecture 5 Introduction to Networking (Finished), Concurrency (Processes and Threads) September 14 th, 2015.
Operating Systems Lecture 2 Processes and Threads Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of.
Chapter 41 Processes Chapter 4. 2 Processes  Multiprogramming operating systems are built around the concept of process (also called task).  A process.
Chapter 3 Advanced Operating System
Recall: Three I/O Methods Synchronous: Wait for I/O operation to complete. Asynchronous: Post I/O request and switch to other work. DMA (Direct Memory.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Operating Systems Lecture 7 OS Potpourri Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of Software.
CSC139 Operating Systems Lecture 4 Thread Dispatching Adapted from Prof. John Kubiatowicz's lecture notes for CS162
Multiprogramming. Readings r Silberschatz, Galvin, Gagne, “Operating System Concepts”, 8 th edition: Chapter 3.1, 3.2.
CS 162 Discussion Section Week 2. Who am I? Haoyuan (HY) Li Office Hours: 1pm-3pm
CS 162 Discussion Section Week 2. Who am I? Wesley Chow Office Hours: 12pm-2pm 411 Soda Does Monday 1-3 work for everyone?
CPS110: Implementing threads Landon Cox. Recap and looking ahead Hardware OS Applications Where we’ve been Where we’re going.
Chapter 4: Threads March 17 th, 2009 Instructor: Hung Q. Ngo Kyung Hee University.
We will focus on operating system concepts What does it do? How is it implemented? Apply to Windows, Linux, Unix, Solaris, Mac OS X. Will discuss differences.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
Introduction to Operating Systems and Concurrency.
Operating Systems CSE 411 CPU Management Sept Lecture 10 Instructor: Bhuvan Urgaonkar.
Goals for Today How do we provide multiprogramming? What are Processes? How are they related to Threads and Address Spaces? Note: Some slides and/or pictures.
MIPS Lab CMPE 142 – Operating Systems. MIPS Simulator First Time Startup Setting Options.
CPS110: Implementing threads on a uni-processor Landon Cox January 29, 2008.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
CS162 Operating Systems and Systems Programming Lecture 5 Introduction to Networking (Finished), Concurrency (Processes and Threads) February 3 rd, 2016.
Multiprogramming. Readings r Chapter 2.1 of the textbook.
Processes and threads.
Process concept.
CSCI 511 Operating Systems Chapter 3,4 (Part A) Processes and Threads
Process Management Process Concept Why only the global variables?
CS 6560: Operating Systems Design
CSCS 511 Operating Systems Ch3, 4 (Part B) Further Understanding Threads Dr. Frank Li Skipped sections 3.5 & 3.6 
Mechanism: Limited Direct Execution
Intro to Processes CSSE 332 Operating Systems
Profs. Anthony D. Joseph and Jonathan Ragan-Kelley
Concurrency: Threads, Address Spaces, and Processes
CSCI 511 Operating Systems Ch3, 4 (Part B) Further Understanding Threads Dr. Frank Li Skipped sections 3.5 & 3.6 
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 13, 2010 Prof. John Kubiatowicz
CS162 Operating Systems and Systems Programming Lecture 3 Thread Dispatching January 30, 2008 Prof. Anthony D. Joseph
CSCI 511 Operating Systems Chapter 3,4 (Part A) Processes and Threads
CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 10, 2007 Prof. John Kubiatowicz
Concurrency: Threads, Address Spaces, and Processes
January 28, 2010 Ion Stoica CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching January.
Process Description and Control
Lecture Topics: 11/1 General Operating System Concepts Processes
Threads Chapter 5 2/17/2019 B.Ramamurthy.
Threads Chapter 5 2/23/2019 B.Ramamurthy.
Chapter 2 Processes and Threads 2.1 Processes 2.2 Threads
Concurrency: Threads, Address Spaces, and Processes
Presentation transcript:

CS162 Operating Systems and Systems Programming Lecture 4 Thread Dispatching September 9, 2009 Prof. John Kubiatowicz

Lec 4.2 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Recall: Modern Process with Multiple Threads Process: Operating system abstraction to represent what is needed to run a single, multithreaded program Two parts: –Multiple Threads »Each thread is a single, sequential stream of execution –Protected Resources: »Main Memory State (contents of Address Space) »I/O state (i.e. file descriptors) Why separate the concept of a thread from that of a process? –Discuss the “thread” part of a process (concurrency) –Separate from the “address space” (Protection) –Heavyweight Process  Process with one thread

Lec 4.3 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Recall: Single and Multithreaded Processes Threads encapsulate concurrency –“Active” component of a process Address spaces encapsulate protection –Keeps buggy program from trashing the system –“Passive” component of a process

Lec 4.4 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Goals for Today Further Understanding Threads Thread Dispatching Beginnings of Thread Scheduling Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following are adapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from my lecture notes by Kubiatowicz.

Lec 4.5 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Classification Real operating systems have either –One or many address spaces –One or many threads per address space Did Windows 95/98/ME have real memory protection? –No: Users could overwrite process tables/System DLLs Mach, OS/2, Linux, Win 95?, Mac OS X, Win NT to XP, Solaris, HP-UX Embedded systems (Geoworks, VxWorks, JavaOS,etc) JavaOS, Pilot(PC) Traditional UNIX MS/DOS, early Macintosh Many One # threads Per AS: ManyOne # of addr spaces:

Lec 4.6 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Thread State State shared by all threads in process/addr space –Contents of memory (global variables, heap) –I/O state (file system, network connections, etc) State “private” to each thread –Kept in TCB  Thread Control Block –CPU registers (including, program counter) –Execution stack – what is this? Execution Stack –Parameters, Temporary variables –return PCs are kept while called procedures are executing

Lec 4.7 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Execution Stack Example Stack holds temporary results Permits recursive execution Crucial to modern languages A(int tmp) { if (tmp<2) B(); printf(tmp); } B() { C(); } C() { A(2); } A(1); A: tmp=2 ret=C+1 Stack Pointer Stack Growth A: tmp=1 ret=exit B: ret=A+2 C: ret=B+1

Lec 4.8 9/9/09Kubiatowicz CS162 ©UCB Fall zero constant 0 1atreserved for assembler 2v0expression evaluation & 3v1function results 4a0arguments 5a1 6a2 7a3 8t0temporary: caller saves...(callee can clobber) 15t7 16s0callee saves... (callee must save) 23s7 24t8 temporary (cont’d) 25t9 26k0reserved for OS kernel 27k1 28gpPointer to global area 29spStack pointer 30fpframe pointer 31raReturn Address (HW) MIPS: Software conventions for Registers Before calling procedure: –Save caller-saves regs –Save v0, v1 –Save ra After return, assume –Callee-saves reg OK –gp,sp,fp OK (restored!) –Other things trashed

Lec 4.9 9/9/09Kubiatowicz CS162 ©UCB Fall 2009 Single-Threaded Example Imagine the following C program: main() { ComputePI(“pi.txt”); PrintClassList(“clist.text”); } What is the behavior here? –Program would never print out class list –Why? ComputePI would never finish

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Use of Threads Version of program with Threads: main() { CreateThread(ComputePI(“pi.txt”)); CreateThread(PrintClassList(“clist.text”)); } What does “CreateThread” do? –Start independent thread running given procedure What is the behavior here? –Now, you would actually see the class list –This should behave as if there are two separate CPUs CPU1CPU2CPU1CPU2 Time CPU1CPU2

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Memory Footprint of Two-Thread Example If we stopped this program and examined it with a debugger, we would see –Two sets of CPU registers –Two sets of Stacks Questions: –How do we position stacks relative to each other? –What maximum size should we choose for the stacks? –What happens if threads violate this? –How might you catch violations? Code Global Data Heap Stack 1 Stack 2 Address Space

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Per Thread State Each Thread has a Thread Control Block (TCB) –Execution State: CPU registers, program counter, pointer to stack –Scheduling info: State (more later), priority, CPU time –Accounting Info –Various Pointers (for implementing scheduling queues) –Pointer to enclosing process? (PCB)? –Etc (add stuff as you find a need) In Nachos: “Thread” is a class that includes the TCB OS Keeps track of TCBs in protected memory –In Array, or Linked List, or …

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Lifecycle of a Thread (or Process) As a thread executes, it changes state: –new: The thread is being created –ready: The thread is waiting to run –running: Instructions are being executed –waiting: Thread waiting for some event to occur –terminated: The thread has finished execution “Active” threads are represented by their TCBs –TCBs organized into queues based on their state

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Ready Queue And Various I/O Device Queues Thread not running  TCB is in some scheduler queue –Separate queue for each device/signal/condition –Each queue can have a different scheduler policy Other State TCB 9 Link Registers Other State TCB 6 Link Registers Other State TCB 16 Link Registers Other State TCB 8 Link Registers Other State TCB 2 Link Registers Other State TCB 3 Link Registers Head Tail Head Tail Head Tail Head Tail Head Tail Ready Queue Tape Unit 0 Disk Unit 0 Disk Unit 2 Ether Netwk 0

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Administrivia Tentative Group assignments now posted on website –Check out the “Group/Section Assignment” link –Please attend your newly assigned section! As you can see, we are a bit unbalanced in sections. –Many of you didn’t listen: you only listed one section without sending me to explain! –Those of you who only selected one section must send me a NEW explaining why you can only make one section »I expect 15 of these messages. Make sure to include your group number and list of members Anyone without a group? –Please come up to talk with me afterwards Sections in this class are mandatory –Go to the section that you have been assigned! –Important information will be given in section –5% of grade is participation

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Administrivia (2) Information about Subversion on Handouts page –Make sure to take a look We understand that there have been problems with the Subversion server –Hopefully will be already fixed Other things on Handouts page –Interesting papers –Synchronization examples –Previous finals/solutions Reader now available at Copy Central on Hearst RSS feeds available (see top of lectures page) Should be reading Nachos code by now! –Start working on the first project –Set up regular meeting times with your group –Try figure out group interaction problems early on

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Dispatch Loop Conceptually, the dispatching loop of the operating system looks as follows: Loop { RunThread(); ChooseNextThread(); SaveStateOfCPU(curTCB); LoadStateOfCPU(newTCB); } This is an infinite loop –One could argue that this is all that the OS does Should we ever exit this loop??? –When would that be?

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Running a thread Consider first portion: RunThread() How do I run a thread? –Load its state (registers, PC, stack pointer) into CPU –Load environment (virtual memory space, etc) –Jump to the PC How does the dispatcher get control back? –Internal events: thread returns control voluntarily –External events: thread gets preempted

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Internal Events Blocking on I/O –The act of requesting I/O implicitly yields the CPU Waiting on a “signal” from other thread –Thread asks to wait and thus yields the CPU Thread executes a yield() –Thread volunteers to give up CPU computePI() { while(TRUE) { ComputeNextDigit(); yield(); } }

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Stack for Yielding Thread How do we run a new thread? run_new_thread() { newThread = PickNewThread(); switch(curThread, newThread); ThreadHouseKeeping(); /* next Lecture */ } How does dispatcher switch to a new thread? –Save anything next thread may trash: PC, regs, stack –Maintain isolation for each thread yield ComputePI Stack growth run_new_thread kernel_yield Trap to OS switch

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 What do the stacks look like? Consider the following code blocks: proc A() { B(); } proc B() { while(TRUE) { yield(); } } Suppose we have 2 threads: –Threads S and T Thread S Stack growth A B(while) yield run_new_thread switch Thread T A B(while) yield run_new_thread switch

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Saving/Restoring state (often called “Context Switch) Switch(tCur,tNew) { /* Unload old thread */ TCB[tCur].regs.r7 = CPU.r7; … TCB[tCur].regs.r0 = CPU.r0; TCB[tCur].regs.sp = CPU.sp; TCB[tCur].regs.retpc = CPU.retpc; /*return addr*/ /* Load and execute new thread */ CPU.r7 = TCB[tNew].regs.r7; … CPU.r0 = TCB[tNew].regs.r0; CPU.sp = TCB[tNew].regs.sp; CPU.retpc = TCB[tNew].regs.retpc; return; /* Return to CPU.retpc */ }

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Switch Details How many registers need to be saved/restored? –MIPS 4k: 32 Int(32b), 32 Float(32b) –Pentium: 14 Int(32b), 8 Float(80b), 8 SSE(128b),… –Sparc(v7): 8 Regs(32b), 16 Int regs (32b) * 8 windows = 136 (32b)+32 Float (32b) –Itanium: 128 Int (64b), 128 Float (82b), 19 Other(64b) retpc is where the return should jump to. –In reality, this is implemented as a jump There is a real implementation of switch in Nachos. –See switch.s »Normally, switch is implemented as assembly! –Of course, it’s magical! –But you should be able to follow it!

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Switch Details (continued) What if you make a mistake in implementing switch? –Suppose you forget to save/restore register 4 –Get intermittent failures depending on when context switch occurred and whether new thread uses register 4 –System will give wrong result without warning Can you devise an exhaustive test to test switch code? –No! Too many combinations and inter-leavings Cautionary tail: –For speed, Topaz kernel saved one instruction in switch() –Carefully documented! »Only works As long as kernel size < 1MB –What happened? »Time passed, People forgot »Later, they added features to kernel (no one removes features!) »Very weird behavior started happening –Moral of story: Design for simplicity

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 What happens when thread blocks on I/O? What happens when a thread requests a block of data from the file system? –User code invokes a system call –Read operation is initiated –Run new thread/switch Thread communication similar –Wait for Signal/Join –Networking CopyFile read run_new_thread kernel_read Trap to OS switch Stack growth

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 External Events What happens if thread never does any I/O, never waits, and never yields control? –Could the ComputePI program grab all resources and never release the processor? »What if it didn’t print to console? –Must find way that dispatcher can regain control! Answer: Utilize External Events –Interrupts: signals from hardware or software that stop the running code and jump to kernel –Timer: like an alarm clock that goes off every some many milliseconds If we make sure that external events occur frequently enough, can ensure dispatcher runs

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009  add $r1,$r2,$r3 subi $r4,$r1,#4 slli $r4,$r4,#2 PC saved Disable All Ints Supervisor Mode Restore PC User Mode Raise priority Reenable All Ints Save registers Dispatch to Handler  Transfer Network Packet from hardware to Kernel Buffers  Restore registers Clear current Int Disable All Ints Restore priority RTI “Interrupt Handler” Example: Network Interrupt An interrupt is a hardware-invoked context switch –No separate step to choose what to run next –Always run the interrupt handler immediately lw$r2,0($r4) lw$r3,4($r4) add$r2,$r2,$r3 sw8($r4),$r2  External Interrupt Pipeline Flush

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Use of Timer Interrupt to Return Control Solution to our dispatcher problem –Use the timer interrupt to force scheduling decisions Timer Interrupt routine: TimerInterrupt() { DoPeriodicHouseKeeping(); run_new_thread(); } I/O interrupt: same as timer interrupt except that DoHousekeeping() replaced by ServiceIO(). Some Routine run_new_thread TimerInterrupt Interrupt switch Stack growth

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Choosing a Thread to Run How does Dispatcher decide what to run? –Zero ready threads – dispatcher loops »Alternative is to create an “idle thread” »Can put machine into low-power mode –Exactly one ready thread – easy –More than one ready thread: use scheduling priorities Possible priorities: –LIFO (last in, first out): »put ready threads on front of list, remove from front –Pick one at random –FIFO (first in, first out): »Put ready threads on back of list, pull them from front »This is fair and is what Nachos does –Priority queue: »keep ready list sorted by TCB priority field

Lec /9/09Kubiatowicz CS162 ©UCB Fall 2009 Summary The state of a thread is contained in the TCB –Registers, PC, stack pointer –States: New, Ready, Running, Waiting, or Terminated Multithreading provides simple illusion of multiple CPUs –Switch registers and stack to dispatch new thread –Provide mechanism to ensure dispatcher regains control Switch routine –Can be very expensive if many registers –Must be very carefully constructed! Many scheduling options –Decision of which thread to run complex enough for complete lecture