CS162 Operating Systems and Systems Programming Lecture 3 Concurrency Processes Threads and Address Spaces September 8 2008 Prof John Kubiatowicz http inst eecs berkeley edu cs162 Review History of OS Why Study To understand how user needs and hardware constraints influenced and will influence operating systems Several Distinct Phases Hardware Expensive Humans Cheap Eniac Multics Hardware Cheaper Humans Expensive PCs Workstations Rise of GUIs Hardware Really Cheap Humans Really Expensive Ubiquitous devices Widespread networking Rapid Change in Hardware Leads to changing OS Batch Multiprogramming Timeshare Graphical UI Ubiquitous Devices Cyberspace Metaverse Gradual Migration of Features into Smaller Machines Situation today is much like the late 60s Small OS 100K lines Large 10M lines 5M browser 100 1000 people years 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 2 Review Migration of OS Concepts and Features 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 3 Review Implementation Issues How is the OS implemented Policy vs Mechanism Policy What do you want to do Mechanism How are you going to do it Should be separated since policies change Algorithms used Linear Tree based Log Structured etc Event models used threads vs event loops Backward compatability issues Very important for Windows 2000 XP Vista POSIX tries to help here System generation configuration How to make generic OS fit on specific hardware 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 4 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 in the following are adapted from slides 2005 Silberschatz Galvin and 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 5 Gagne Many slides Gagne generated from my lecture notes Concurrency Thread of execution Independent Fetch Decode Execute loop Operating in some Address space Uniprogramming one thread at a time MS DOS early Macintosh Batch processing Easier for operating system builder Get rid concurrency by defining it away Does this make sense for personal computers Multiprogramming more than one thread at a time Multics UNIX Linux OS 2 Windows NT 2000 XP Mac OS X Often called multitasking but multitasking has other meanings talk about this later ManyCore Multiprogramming right 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 6 The Basic Problem of Concurrency The basic problem of concurrency involves resources Hardware single CPU single DRAM single I O devices Multiprogramming API users think they have exclusive access to shared resources OS Has to coordinate all activity Multiple users I O interrupts How can it keep all these things straight Basic Idea Use Virtual Machine abstraction Decompose hard problem into simpler ones Abstract the notion of an executing program Then worry about multiplexing these abstract machines Dijkstra did this for the THE system Few thousand lines vs 1 million lines in OS 360 1K bugs 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 7 Recall 61C What happens during execution Addr 232 1 R0 R31 F0 F30 PC Fetch Exec Execution sequence 9 8 07 Data1 Data0 Inst237 Inst236 Inst5 Inst4 Inst3 Inst2 Inst1 Inst0 Fetch Instruction at PC Decode Execute possibly using registers Write results to registers mem PC Next Instruction PC Addr 0 Repeat Kubiatowicz CS162 UCB Fall 2008 PC PC PC PC Lec 3 8 How can we give the illusion of multiple processors CPU1 CPU2 CPU3 CPU1 Shared Memory CPU2 CPU3 CPU1 CPU2 Time Assume a single processor How do we provide the illusion of multiple processors Multiplex in time Each virtual CPU needs a structure to hold Program Counter PC Stack Pointer SP Registers Integer Floating point others How switch from one CPU to the next Save PC SP and registers in current state block Load PC SP and registers from new state block What triggers switch Timer voluntary yield I O other things Kubiatowicz CS162 UCB Fall 2008 9 8 07 Lec 3 9 Properties of this simple multiprogramming technique All virtual CPUs share same non CPU resources I O devices the same Memory the same Consequence of sharing Each thread can access the data of every other thread good for sharing bad for protection Threads can share instructions good for sharing bad for protection Can threads overwrite OS functions This unprotected model common in Embedded applications Windows 3 1 Machintosh switch only with yield Windows 95 ME switch with both yield and timer 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 10 Modern Technique SMT Hyperthreading Hardware technique Exploit natural properties of superscalar processors to provide illusion of multiple processors Higher utilization of processor resources Can schedule each thread as if were separate CPU However not linear speedup If have multiprocessor should schedule each processor first Original technique called Simultaneous Multithreading See http www cs washington edu research smt Alpha SPARC Pentium 4 Hyperthreading 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 11 Power 5 Administriva Second Try for Project Signup Still working on section assignments Wednesday 2 3 oversubscribed Thinking of trying to add Wednesday 1 2 remove Tuesday 1 2 Would this help Also some people signed up twice Some people didn t sign up at all Try again Project Signup Group Section Assignment Link Due date Tomorrow 9 9 by 11 59pm Sections Go to Telebears assigned Section this week Tue Wed 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 12 Administrivia 2 Cs162 xx accounts Make sure you got an account form If you haven t logged in yet you need to do so Email addresses We need an email address from you If you haven t given us one already you should get prompted when you log in again or type register Wednesday Start Project 1 Go to Nachos page and start reading up Note that all the Nachos code will be printed in your reader TBA 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 13 How to protect threads from one another Need three important things 1 Protection of memory Every task does not have access to all memory 2 Protection of I O devices Every task does not have access to every device 3 Preemptive switching from task to task Use of timer Must not be possible to disable timer from usercode 9 8 07 Kubiatowicz CS162 UCB Fall 2008 Lec 3 14 Recall Program s Address Space For a 32 bit processor there are 232 4 billion addresses What happens when you read or write to an address Perhaps Nothing Perhaps acts like regular memory Perhaps ignores writes Perhaps causes I O operation Program Address
View Full Document
Unlocking...