Transcript lecture9-sept25

Operating Systems
CSE 411
CPU Management
Sept. 25 2006 - 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
• Used to notify a process that
something has happened that
it needs to attend to
• Interrupt/trap handlers are
implemented by the OS
• Signal handlers may be
implemented by the process
• Usually handled right away
• Handled when the process is
scheduled next
• Generated and handled
synchronously
• Interrupts asynch. generated,
traps synch. generated
– 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)
Signal due indicators
Signal is not due
Signal is due
OS
Parent of P
ISR run; assume Sys call done;
P scheduled again Par scheduled
PCB of P
Runs SIGSEGV
handler; dumps core
and exits
time
Timer interrupt
System call
(trap)
Timer interrupt
Calls kill() to
Accesses illegal
send a signal to P memory location
(trap)
(trap)
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
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