Operating Systems CSE 411

1. Operating SystemsCSE 411 CPU Management Sept. 25 2006 - Lecture 9 Instructor: Bhuvan Urgaonkar

2. Last time • Pre-emptive scheduling • Lottery, Reservation, … • Today • Signals • Introduction to accounting • CPU accounting • Threads

3. Interrupts/Traps and Signals Compared • 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

4. Interrupts/Traps versus Signals • 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? • 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

5. Signals • 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

6. 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

7. 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 */

8. System calls related to signals • kill(signal_num, pid) - to send a signal • signal(signal_num, handler) - to handle it

9. Signal Handling (Visual) Signal due indicators PCB of P Signal is not due Signal is due Runs SIGSEGV handler; dumps core and exits OS Parent of P ISR run; assume P scheduled again Sys call done; Par scheduled time Timer interrupt System call (trap) Timer interrupt Calls kill() to send a signal to P (trap) Accesses illegal memory location (trap) These are the events that P sees (its view of what is going on)

10. Some example programs to show signal handling in UNIX

11. CPU Accounting

12. CPU Accounting • OS keeps track of each process’s CPU usage • Scheduler needs this information • Billing in commercial settings • E.g., Sun’s Grid: $1 per CPU-hour • Prevent resource exhaustion due to malicious or erroneous processes • E.g., fork bomb! • Solution: Limit the number of processes a process can fork • Lets look at the top utility • OS provides syscalls for getting certain usage information • Look at getrusage() • Issue: Who should be charged for CPU usage of the OS? • Consider the example of an I/O-intensive process • Suggested reading: “resource containers” paper (not part of the syllabus)

13. Threads

14. What is a Thread? • A basic unit of CPU utilization like a process (not necessarily known to the OS though) • “Smaller” than a process • Part of a process • Shares code + data + some other OS resources with other threads that belong to the same process • Files and signal handlers

15. User Threads • Thread management done by user-level threads library • OS doesn’t know about the existence of these threads • Three primary thread libraries: • POSIX Pthreads • Win32 threads • Java threads

16. Kernel Threads • OS sees and manages these threads • OS provides system calls to create, terminate, etc. (just like the system calls it provides for processes) • Examples • Windows XP/2000 • Solaris • Linux • Tru64 UNIX • Mac OS X

17. Benefits • Responsiveness • Resource Sharing • Economy • Utilization of MP Architectures

18. Multithreading Models • Many-to-One • One-to-One • Many-to-Many

19. Many-to-One • Many user-level threads mapped to single kernel thread • Examples: • Solaris Green Threads • GNU Portable Threads

20. Many-to-One Model

21. One-to-One • Each user-level thread maps to kernel thread • Examples • Windows NT/XP/2000 • Linux • Solaris 9 and later

22. One-to-one Model

23. Many-to-Many Model • Allows many user level threads to be mapped to many kernel threads • Allows the operating system to create a sufficient number of kernel threads • Solaris prior to version 9 • Windows NT/2000 with the ThreadFiber package

24. Many-to-Many Model

25. Two-level Model • Similar to M:M, except that it allows a user thread to be bound to kernel thread • Examples • IRIX • HP-UX • Tru64 UNIX • Solaris 8 and earlier

26. Two-level Model