1. Operating Systems CMPSC 473 Processes (6) September 24 2008 - Lecture 12 Instructor: Bhuvan Urgaonkar

2. Announcements Quiz 1 is out and due in at midnight next M Suggested reading: Chapter 4 of SGG Honors credits –Still possible to enroll –Email me if you are interested –Extra work in projects

3. Overview of Process- related Topics How a process is born –Parent/child relationship –fork, clone, … How it leads its life –Loaded: Later in the course –Executed CPU scheduling Context switching Where a process “lives”: Address space –OS maintains some info. for each process: PCB –Process = Address Space + PCB How processes request services from the OS –System calls How processes communicate Threads (user and kernel-level) How processes synchronize How processes die Done Partially done Done Finish today Start today

4. Multi-threading Models User-level thread libraries –E.g., the one provided with Project 1 –Implementation: You are expected to gain this understanding as you work on Project 1 –Pop quiz: Context switch overhead smaller. Why? –What other overheads are reduced? Creation? Removal? Kernel-level threads There must exist some relationship between user threads and kernel threads –Why? Which is better?

5. Multi-threading Models: Many-to-one Model Thread management done by user library Context switching, creation, removal, etc. efficient (if designed well) Blocking call blocks the entire process No parallelism on uPs? Why? Green threads library on Solaris k Kernel thread User thread

6. Multi-threading Models: One-to-many Model Each u-l thread mapped to one k-l thread Allows more concurrency –If one thread blocks, another ready thread can run –Can exploit parallelism on uPs Popular: Linux, several Windows (NT, 2000, XP) kkkk Kernel thread User thread

7. Multi-threading Models: Many-to-many Model # u-l threads >= #k-l threads Best of both previous approaches? kkk Kernel thread User thread

8. Multi-threading Models: Many-to-many Model (2) Popular variation on many-to-many model Two-level model IRIX, HP-UX, Tru64 UNIX, Older than Solaris 9 Pros? Cons? kkkk Kernel thread User thread

9. Popular Thread Libraries Pthreads –The POSIX standard (IEEE 1003.1c) defining an API for thread creation and synchronization –Specification NOT implementation –Recall 311 and/or Check out Fig 4.6 –You will use this in Project 1 Win32 threads Java threads –JVM itself is at least a thread for the host OS –Different implementations for different OSes

10. Thread-specific Data Often multi-thread programs would like to have each thread have access to some data all for itself Most libraries provide support for this including Pthreads, Win32, Java’s lib.

11. Approach #3: User or kernel support to automatically share code, data, files! E.g., a Web browser Share code, data, files (mmaped), via shared memory mechanisms (coming up) –Burden on the programmer Better yet, let kernel or a user-library handle sharing of these parts of the address spaces and let the programmer deal with synchronization issues –User-level and kernel-level threads URL parsing processNetwork sending process Network reception process Interprets response, composes media together and displays on browser screen In virtual memory codedata files registersstack heap registersstackregistersstackregistersstack threads

12. Approach #3: User or kernel support to automatically share code, data, files! URL parsing processNetwork sending process Network reception process Interprets response, composes media together and displays on browser screen In virtual memory codedata files registersstack heap registersstackregistersstackregistersstack threads heap E.g., a Web browser Share code, data, files (mmaped), via shared memory mechanisms (coming up) –Burden on the programmer Better yet, let kernel or a user-library handle sharing of these parts of the address spaces and let the programmer deal with synchronization issues –User-level and kernel-level threads

13. Scheduler Activations Kernel provides LWPs that appear like processor to the u-l library Upcall: A way for the kernel to notify an application about certain events –Similar to signals E.g., if a thread is about to block, kernel makes an upcall and allocates it a new LWP U-l runs an upcall handler that may schedule another eligible thread on the new LWP Similar upcall to inform application when the blocking operation is done Read Sec 4.4.6 Paper by Tom Anderson (Washington) in early 90s Pros and cons? k LWP Kernel thread User thread Lightweight process

14. Costs/Overheads of a Context Switch Direct/apparent –Time spent doing the switch described in previous lectures –Fixed (more or less) Indirect/hidden costs –Cache pollution –Effect of TLB pollution (will study this when we get to Virtual Memory Management) –Workload dependent

15. User-level vs Kernel-level Threads Make your own list based on previous lectures Potential exam questions here!

16. Event-driven Programming Asynchronous I/O Pros and cons

17. Interrupts/Traps Recap interrupt/trap –Used to notify the OS that something has happened that it needs to attend to E.g. 1: Network packet arrived at the Ethernet card E.g. 2: Process made a system call E.g. 3: Process performed division by zero E.g. 4: CPU about to melt! –Interrupt/trap handlers implemented by the OS; their addresses stored at fixed locations indexed by their numbers –Usually handled right away Linux: Top-half right away, bottom-half at leisure Interrupts: Asynchronous generation, synchronous handling Traps: Synchronous generation and handling

18. Interrupts/Traps versus Signals Used to notify the OS that something has happened that it needs to attend to Interrupt/trap handlers are implemented by the OS Usually handled right away Interrupts asynch. generated, traps synch. generated Used to notify a process that something has happened that it needs to attend to Signal handlers may be implemented by the process Handled when the process is scheduled next Generated and handled synchronously –May be due to an asynch. interrupt, but the signal will be generated synch. WHY?

19. Signals Signals are a message-passing based IPC mechanism –Communication between processes –Communication between kernel and processes Fixed number of signals defined by the OS and made known to the processes –UNIX: signal.h A process may implement its own handler for one or more signals –Allowed for most signals, not allowed for SIGKILL –Each PCB has indicators for which signals were received and are due –Upon getting scheduled, the handler for signals received are executed in some order Okay from the process point of view since it is unaware of when it is being scheduled or taken off the CPU

20. More on signals Each signal has a default action which is one of the following: –The signal is discarded after being received – The process is terminated after the signal is received – A core file is written, then the process is terminated – Stop the process after the signal is received Each signal defined by the system falls into one of five classes: –Hardware conditions – Software conditions – Input/output notification –Process control – Resource control

21. Examples of signals SIGHUP 1 /* hangup */ SIGINT 2 /* interrupt */ SIGQUIT 3 /* quit */ SIGILL 4 /* illegal instruction */ SIGABRT 6 /* used by abort */ SIGKILL 9 /* hard kill */ SIGALRM 14 /* alarm clock */ SIGCONT 19 /* continue a stopped process */ SIGCHLD 20 /* to parent on child stop or exit */