DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 4 Thread Dispatching

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162Operating Systems andSystems ProgrammingLecture 4Thread DispatchingSeptember 9, 2009Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 4.29/9/09 Kubiatowicz CS162 ©UCB Fall 2009Recall: 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 threadLec 4.39/9/09 Kubiatowicz CS162 ©UCB Fall 2009Recall: 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 processLec 4.49/9/09 Kubiatowicz CS162 ©UCB Fall 2009Goals for Today• Further Understanding Threads• Thread Dispatching• Beginnings of Thread SchedulingNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from my lecture notes by Kubiatowicz.Lec 4.59/9/09 Kubiatowicz CS162 ©UCB Fall 2009Classification• 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 DLLsMach, OS/2, Linux,Win 95?, Mac OS X,Win NT to XP, Solaris, HP-UXEmbedded systems (Geoworks, VxWorks, JavaOS,etc)JavaOS, Pilot(PC)Traditional UNIXMS/DOS, early MacintoshManyOne# threadsPer AS:ManyOne# of addrspaces:Lec 4.69/9/09 Kubiatowicz CS162 ©UCB Fall 2009Thread 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 executingLec 4.79/9/09 Kubiatowicz CS162 ©UCB Fall 2009Execution Stack Example• Stack holds temporary results• Permits recursive execution• Crucial to modern languagesA(int tmp) {if (tmp<2)B();printf(tmp);}B() {C();}C() {A(2);}A(1);A: tmp=2ret=C+1StackPointerStack GrowthA: tmp=1ret=exitB: ret=A+2C: ret=B+1Lec 4.89/9/09 Kubiatowicz CS162 ©UCB Fall 20090 zero constant 01 at reserved for assembler2 v0 expression evaluation &3 v1 function results4 a0 arguments5 a16 a27 a38 t0 temporary: caller saves. . . (callee can clobber)15 t716 s0 callee saves. . . (callee must save)23 s724 t8 temporary (cont’d)25 t926 k0 reserved for OS kernel27 k128 gp Pointer to global area29 sp Stack pointer30 fp frame pointer31 ra Return 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 trashedLec 4.99/9/09 Kubiatowicz CS162 ©UCB Fall 2009Single-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 finishLec 4.109/9/09 Kubiatowicz CS162 ©UCB Fall 2009Use 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 shouldbehave as if there are two separate CPUsCPU1 CPU2 CPU1 CPU2Time CPU1 CPU2Lec 4.119/9/09 Kubiatowicz CS162 ©UCB Fall 2009Memory 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 choosefor the stacks?– What happens if threads violate this?– How might you catch violations?CodeGlobal DataHeapStack 1Stack 2Address SpaceLec 4.129/9/09 Kubiatowicz CS162 ©UCB Fall 2009Per 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 4.139/9/09 Kubiatowicz CS162 ©UCB Fall 2009Lifecycle 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 stateLec 4.149/9/09 Kubiatowicz CS162 ©UCB Fall 2009Ready 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 policyOtherStateTCB9LinkRegistersOtherStateTCB6LinkRegistersOtherStateTCB16LinkRegistersOtherStateTCB8LinkRegistersOtherStateTCB2LinkRegistersOtherStateTCB3LinkRegistersHeadTailHeadTailHeadTailHeadTailHeadTailReadyQueueTapeUnit 0DiskUnit 0DiskUnit 2EtherNetwk 0Lec 4.159/9/09 Kubiatowicz CS162 ©UCB Fall 2009Administrivia• 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 email to explain!–Those of you


View Full Document

Berkeley COMPSCI 162 - Lecture 4 Thread Dispatching

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 4 Thread Dispatching
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 4 Thread Dispatching and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 4 Thread Dispatching 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?