Operating Systems CSE 411 CPU Management Sept Lecture 9 Instructor: Bhuvan Urgaonkar

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

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

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?

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

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

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

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

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

Some example programs to show signal handling in UNIX

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)

Threads

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

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

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

Benefits Responsiveness Resource Sharing Economy Utilization of MP Architectures

Multithreading Models Many-to-One One-to-One Many-to-Many

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

Many-to-One Model

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

One-to-one Model

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

Many-to-Many Model

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

Two-level Model