Presentations

2 Process&Threads

Description
threads
Categories
Published
of 4
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  Operating Systems Lecture Notes Lecture 2 Processes and Threads ã A process is an execution stream in the context of a particular process state. o An execution stream is a sequence of instructions. o Process state determines the effect of the instructions. It usually includes (but is not restricted to):  Registers  Stac  !emory (global ariables and dynamically allocated memory)  #pen file tables  Signal management information $ey concept: processes are separated: no process can directly affect the state of another process. ã Process is a ey #S abstraction that users see % the en ironment you interact &ith &hen you use a computer is built up out of processes. o 'he shell you type stuff into is a process. o hen you execute a program you ha e ust compiled* the #S generates a process to run the program. o +our  bro&ser is a process. ã #rgani,ing system acti ities around processes has pro ed to be a useful &ay of separating out different acti ities into coherent units. ã '&o concepts: uniprogramming and multiprogramming. o -niprogramming: only one process at a time. 'ypical example: #S. Problem: users often &ish to perform more than one acti ity at a time (load a remote file &hile editing a program* for example)* and uniprogramming does not allo& this. So #S and other uniprogrammed systems put in things lie memory%resident  programs that in oed asynchronously* but still ha e separation problems. #ne ey problem &ith #S is that there is no memory protection % one program may &rite the memory of another program* causing &eird bugs.  o !ultiprogramming: multiple processes at a time. 'ypical of -nix plus all currently en isioned ne& operating systems. Allo&s system to separate out acti ities cleanly. ã !ultiprogramming introduces the resource sharing problem % &hich processes get to use the physical resources of the machine &hen/ #ne crucial resource: 0P-. Standard solution is to use preempti e multitasing % #S runs one process for a &hile* then taes the 0P- a&ay from that process and lets another process run. !ust sa e and restore  process state. $ey issue: fairness. !ust ensure that all processes get their fair share of the 0P-. ã 1o& does the #S implement the process abstraction/ -ses a context s&itch to s&itch from running one process to running another process. ã 1o& does machine implement context s&itch/ A processor has a limited amount of  physical resources. 2or example* it has only one register set. 3ut e ery process on the machine has its o&n set of registers. Solution: sa e and restore hard&are state on a context s&itch. Sa e the state in Process 0ontrol 3loc (P03). hat is in P03/ ependson the hard&are. o Registers % almost all machines sa e registers in P03. o Processor Status ord. o hat about memory/ !ost machines allo& memory from multiple processes to coexist in the physical memory of the machine. Some may require !emory !anagement -nit (!!-) changes on a context s&itch. 3ut* some early personal computers s&itched all of process4s memory out to dis (555). ã #perating Systems are fundamentally e ent%dri en systems % they &ait for an e ent to happen* respond appropriately to the e ent* then &ait for the next e ent. 6xamples: o -ser hits a ey. 'he eystroe is echoed on the screen. o A user program issues a system call to read a file. 'he operating system figures out &hich dis blocs to bring in* and generates a request to the dis controller to read the dis blocs into memory. o 'he dis controller finishes reading in the dis bloc and generates and interrupt. 'he #S mo es the read data into the user program and restarts the user program. o A !osaic or 7etscape user ass for a -R8 to be retrie ed. 'his e entually generates requests to the #S to send request pacets out o er the net&or to a remote  ser er. 'he #S sends the pacets. o 'he response pacets come bac from the  ser er* interrupting the  processor. 'he #S figures out &hich process should get the pacets* then routes the pacets to that process.  o 'ime%slice timer goes off. 'he #S must sa e the state of the current process* choose another process to run* the gi e the 0P- to that process. ã hen build an e ent%dri en system &ith se eral distinct serial acti ities* threads are a ey structuring mechanism of the #S. ã A thread is again an execution stream in the context of a thread state. $ey difference  bet&een processes and threads is that multiple threads share parts of their state. 'ypically*allo& multiple threads to read and &rite same memory. (Recall that no processes could directly access memory of another process). 3ut* each thread still has its o&n registers. Also has its o&n stac* but other threads can read and &rite the stac memory. ã hat is in a thread control bloc/ 'ypically ust registers. on4t need to do anything to the !!- &hen s&itch threads* because all threads can access same memory. ã 'ypically* an #S &ill ha e a separate thread for each distinct acti ity. In particular* the #S &ill ha e a separate thread for each process* and that thread &ill perform #S acti ities on behalf of the process. In this case &e say that each user process is baced by a ernel thread. o hen process issues a system call to read a file* the process4s thread &ill tae o er* figure out &hich dis accesses to generate* and issue the lo& le el instructions required to start the transfer. It then suspends until the dis finishes reading in the data. o hen process starts up a remote '0P connection* its thread handles the lo&%le el details of sending out net&or pacets. ã 1a ing a separate thread for each acti ity allo&s the programmer to program the actions associated &ith that acti ity as a single serial stream of actions and e ents. Programmer does not ha e to deal &ith the complexity of interlea ing multiple acti ities on the same thread. ã hy allo& threads to access same memory/ 3ecause inside #S* threads must coordinate their acti ities ery closely. o If t&o processes issue read file system calls at close to the same time* must mae sure that the #S seriali,es the dis requests appropriately. o hen one process allocates memory* its thread must find some free memory and gi e it to the process. !ust ensure that multiple threads allocate disoint pieces of memory. 1a ing threads share the same address space maes it much easier to coordinate acti ities% can build data structures that represent system state and ha e threads read and &rite datastructures to figure out &hat to do &hen they need to process a request.  ã #ne complication that threads must deal &ith: asynchrony. Asynchronous e ents happen arbitrarily as the thread is executing* and may interfere &ith the thread4s acti ities unless the programmer does something to limit the asynchrony. 6xamples: o An interrupt occurs* transferring control a&ay from one thread to an interrupt handler. o A time%slice s&itch occurs* transferring control from one thread to another. o '&o threads running on different processors read and &rite the same memory. ã Asynchronous e ents* if not properly controlled* can lead to incorrect beha ior. 6xamples: o '&o threads need to issue dis requests. 2irst thread starts to program dis controller (assume it is memory%mapped* and must issue multiple &rites to specify a dis operation). In the meantime* the second thread runs on a different  processor and also issues the memory%mapped &rites to program the dis controller. 'he dis controller gets horribly confused and reads the &rong dis  bloc. o '&o threads need to &rite to the display. 'he first thread starts to build its request* but before it finishes a time%slice s&itch occurs and the second thread starts its request. 'he combination of the t&o threads issues a forbidden request sequence* and smoe starts pouring out of the display. o 2or accounting reasons the operating system eeps trac of ho& much time is spent in each user program. It also eeps a running sum of the total amount of time spent in all user programs. '&o threads increment their local counters for their processes* then concurrently increment the global counter. 'heir increments interfere* and the recorded total time spent in all user processes is less than the sum of the local times. ã So* programmers need to coordinate the acti ities of the multiple threads so that these  bad things don4t happen. $ey mechanism: synchroni,ation operations. 'hese operations allo& threads to control the timing of their e ents relati e to e ents in other threads. Appropriate use allo&s programmers to a oid problems lie the ones outlined abo e.
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks