1 / 26

Operating Systems CSE 411

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

jon
Télécharger la présentation

Operating Systems CSE 411

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related