Exceptional Control Flow Oct 24, 2000

Slides:



Advertisements
Similar presentations
More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
Advertisements

1 Exceptions, Interrupts & Traps Operating System Hebrew University Spring 2007.
Carnegie Mellon 1 Exceptional Control Flow: Exceptions and Processes /18-243: Introduction to Computer Systems 13 th Lecture, June 15, 2011 Instructors:
Exceptional Control Flow Processes Today. Control Flow Processors do only one thing: From startup to shutdown, a CPU simply reads and executes (interprets)
University of Washington Today Midterm grades posted  76. HW 3 due Lab 4 fun! 1.
Processes Topics Process context switches Creating and destroying processes CS 105 “Tour of the Black Holes of Computing!”
1 Processes Professor Jennifer Rexford
Exceptional Control Flow Part I September 22, 2008 Topics Exceptions Process context switches Creating and destroying processes class11.ppt ,
Advanced OS Chapter 3p2 Sections 3.4 / 3.5. Interrupts These enable software to respond to signals from hardware. The set of instructions to be executed.
Exceptional Control Flow Part I Topics Exceptions Process context switches Creating and destroying processes class14.ppt CS 123.
Section A (March 14) Outline Exceptions Process Signals Non-local jumps Reminders Lab4: Due Next Thursday TA: Kun Gao Shamelessly Modified from Minglong.
Exceptional Control Flow Part I Topics Exceptions Process context switches Creating and destroying processes.
Exceptional Control Flow Part II Topics Process Hierarchy Signals CS213.
Process. Process Concept Process – a program in execution Textbook uses the terms job and process almost interchangeably A process includes: – program.
Fabián E. Bustamante, Spring 2007 Exceptional Control Flow Part I Today Exceptions Process context switches Creating and destroying processes Next time.
Introduction to Processes CS Intoduction to Operating Systems.
Exceptional Control Flow Part I March 4, 2004 Topics Exceptions Process context switches Creating and destroying processes class16.ppt “The course.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Processes Topics Process context switches Creating and destroying processes CS 105 “Tour of the Black Holes of Computing!”
CSC 2405 Computer Systems II Exceptions Mini-Lecture Traps & Interrupts.
System-level programming II: Processes Feb 24, 2000 Topics User-level view of processes Exceptions Context switches Higher level control flow mechanisms.
University of Amsterdam Computer Systems – Processes Arnoud Visser 1 Computer Systems Processes.
Program Translation and Execution II: Processes Oct 1, 1998 Topics User-level view of processes Implementation of processes setjmp/longjmp class12.ppt.
Exceptional Control Flow Part I Topics Exceptions Process context switches Creating and destroying processes class16.ppt.
Exceptional Control Flow Topics Exceptions except1.ppt CS 105 “Tour of the Black Holes of Computing”
University of Washington Exceptional Control Flow The Hardware/Software Interface CSE351 Winter 2013.
Exceptional Control Flow I March 12, 2002
Exceptional Control Flow II Oct 23, 2001 Topics Exceptions Process context switches class17.ppt “The course that gives CMU its Zip!”
Overview of today’s lecture Re-view of the previous lecture Process management models and state machines (cont’d from the previous lecture) What is in.
University of Washington Roadmap 1 car *c = malloc(sizeof(car)); c->miles = 100; c->gals = 17; float mpg = get_mpg(c); free(c); Car c = new Car(); c.setMiles(100);
Exceptional Control Flow
Recitation 7 (Oct. 25) Outline Minglong Shao Office hours: Reminders
Section 8: Processes What is a process Creating processes Fork-Exec
Exceptional Control Flow & Processes
Exceptional Control Flow
Exceptional Control Flow
Protection of System Resources
Exceptional Control Flow
Overview of today’s lecture
Unix Process Management
Exceptional Control Flow Part I
Exceptional Control Flow
Instructors: Anthony Rowe, Seth Goldstein and Gregory Kesden
Processes in Unix, Linux, and Windows
CS703 – Advanced Operating Systems
Exceptional Control Flow: System Calls, Page Faults etc.
Processes in Unix, Linux, and Windows
Lecture 5: Process Creation
Exceptional Control Flow
More examples How many processes does this piece of code create?
Exceptional Control Flow I
Processes in Unix, Linux, and Windows
Exceptional Control Flow Part I Mar. 11, 2003
Exceptional Control Flow Part I
Exceptions Control Flow
CSCE 313 – Introduction to UNIx process
CS 105 “Tour of the Black Holes of Computing!”
Processes Prof. Ikjun Yeom TA – Mugyo
Exceptional Control Flow
CS201 - Lecture 17 Exceptions
CS 105 “Tour of the Black Holes of Computing!”
CS 105 “Tour of the Black Holes of Computing!”
Lecture 6: Multiprogramming and Context Switching
Exceptional Control Flow
CS 105 “Tour of the Black Holes of Computing!”
Processes in Unix, Linux, and Windows
Processes in Unix and Windows
CS510 Operating System Foundations
Exceptional Control Flow & Processes October 2, 2008
Chapter 3 Process Description and Control
Presentation transcript:

Exceptional Control Flow Oct 24, 2000 15-213 “The course that gives CMU its Zip!” Exceptional Control Flow Oct 24, 2000 Topics Exceptions Process context switches Signals Non-local jumps class17.ppt

Control flow From startup to shutdown, a CPU simply reads and executes (interprets) a sequence of instructions, one at a time. This sequence is the system’s physical control flow (or flow of control). Physical control flow <startup> inst1 inst2 inst3 … instn <shutdown> Time

Altering the control flow So far in class, we’ve discussed two mechanisms for changing the control flow: jumps and branches call and return using the stack discipline. both react to changes in program state. These are insufficient for a useful system difficult for the CPU to react to changes in system state. data arrives from a disk or a network adapter. instruction divides by zero user hitting ctl-c at the keyboard system timer expires Real systems need mechanisms for “exceptional control flow”

Exceptional control flow Mechanisms for exceptional control flow exists at all levels of a computer system. Low level mechanism: exceptions change in control flow in response to a system event (i.e., change in system state) implemented as a combination of both hardware and OS software Higher level mechanisms: process context switch signals nonlocal jumps (setjmp/longjmp) implemented by either: OS software (context switch and signals). C language runtime library: nonlocal jumps.

System context for exceptions Keyboard Mouse Modem Printer Processor Interrupt controller Keyboard controller Serial port controller Parallel port controller Local/IO Bus Memory IDE disk controller SCSI controller Video adapter Network adapter SCSI bus disk Display Network disk cdrom

Exceptions An exception is a transfer of control to the OS in response to some event (i.e. change in processor state) User Process OS event current exception next exception processing by exception handler exception return (optional)

Interrupt vectors ... ... 1. Each type of event has Exception numbers code for exception handler 0 1. Each type of event has a unique exception number k 2. Jump table (interrupt vector) entry k points to a function (exception handler). 3. Handler k is called each time exception k occurs. interrupt vector code for exception handler 1 1 code for exception handler 2 2 ... ... n-1 code for exception handler n-1

Asynchronous exceptions (interrupts) Caused by events (changes in state) external to the processor Indicated by setting the processor’s interrupt pin handler returns to “next” instruction. Examples: I/O interrupts hitting ctl-c at the keyboard arrival of a packet from a network arrival of a data sector from a disk Hard reset interrupt hitting the reset button Soft reset interrupt hitting ctl-alt-delete on a PC

Synchronous exceptions Caused by events (changes in state) that occur as a result of executing an instruction: Traps intentional returns control to “next” instruction Examples: system calls, breakpoint traps Faults unintentional but possibly recoverable either re-executes faulting (“current”) instruction or aborts. Examples: page faults (recoverable), protection faults (unrecoverable). Aborts unintentional and unrecoverable aborts current program Examples: parity error, machine check.

Processes Def: A process is an instance of a running program. One of the most profound ideas in computer science. Process provides each program with two key abstractions: Logical control flow gives each program the illusion that it has exclusive use of the CPU. Private address space gives each program the illusion that has exclusive use of main memory.

Logical control flows Each process has its own logical control flow Process A Process B Process C Time

Concurrent processes Two processes run concurrently (are concurrent) if their flows overlap in time. Otherwise, they are sequential. Examples: Concurrent: A & B, A&C Sequential: B & C Time Process A Process B Process C

User view of concurrent processes Control flows for concurrent processes are physically disjoint in time. However, we can think of concurrent processes are running in parallel with each other. Process A Process B Process C Time

Context switching Processes are managed by a shared chunk of OS code called the kernel Important: the kernel is not a separate process, but rather runs as part of some user process Control flow passes from one process to another via a context switch. Process A code Process B code user code context switch kernel code Time user code context switch kernel code user code

Private address spaces Each process has its own private address space. 0xffffffff kernel virtual memory (code, data, heap, stack) memory invisible to user code 0xc0000000 user stack (created at runtime) %esp (stack pointer) memory mapped region for shared libraries 0x40000000 brk run-time heap (managed by malloc) read/write segment (.data, .bss) loaded from the executable file read-only segment (.init, .text, .rodata) 0x08048000 unused

fork: Creating new processes int fork(void) creates a new process (child process) that is identical to the calling process (parent process) returns 0 to the child process returns child’s pid to the parent process if (fork() == 0) { printf(“hello from child\n”); } else { printf(“hello from parent\n”); Fork is interesting (and often confusing) because it is called once but returns twice

exit: Destroying processes void exit(int status) exits a process atexit() registers functions to be executed upon exit void cleanup(void) { printf(“cleaning up\n”); } main() { atexit(cleanup); if (fork() == 0) { printf(“hello from child\n”); else { printf(“hello from parent\n”); exit();

wait: Synchronizing with children int wait(int *child_status) suspends current process until one of its children terminates return value = the pid of the child process that terminated if child_status != NULL, then the object it points to will be set to a status indicating why the child process terminated main() { int child_status; if (fork() == 0) { printf(“hello from child\n”); } else { printf(“hello from parent\n”); wait(&child_status); printf(“child has terminated\n”); exit();

exec: Running new programs int execl(char *path, char *arg0, char *arg1, …, 0) loads and runs executable at path with args arg0, arg1, … path is the complete path of an executable arg0 becomes the name of the process typically arg0 is either identical to path, or else it contains only the executable filename from path “real” arguments to the executable start with arg1, etc. list of args is terminated by a (char *)0 argument returns -1 if error, otherwise doesn’t return! main() { if (fork() == 0) { execl(“/usr/bin/cp”,“cp”,“foo”,“bar”,0); } wait(NULL); printf(“copy completed\n”); exit();

Linux process hierarchy [0] init [1] Daemon e.g. snmp shell child child child grandchild grandchild

Linux Startup: Step 1 1. Pushing reset button loads the PC with the address of a small bootstrap program. 2. Bootstrap program loads the boot block (disk block 0). 3. Boot block program loads kernel (e.g., /vmunix) 4. Boot block program passes control to kernel. 5. Kernel handcrafts the data structures for process 0. [0] process 0: handcrafted kernel process process 1: user mode process fork() and exec(/sbin/init) init [1]

Linux Startup: Step 2 [0] init forks new processes as per /etc/inittab the /etc/inittab file /etc/inittab init [1] Daemons e.g. ftpd, httpd getty forks a getty (get tty or get terminal) for the console

Linux Startup: Step 3 [0] init [1] login getty execs a login program

Linux Startup: Step 4 [0] init [1] login gets user’s login and password if OK, it execs a shell if not OK, it execs another getty tcsh

Example: Loading and running programs from a shell /* read command line until EOF */ while (read(stdin, buffer, numchars)) { <parse command line> if (<command line contains ‘&’>) background_process = TRUE; else background_process = FALSE; /* for commands not in the shell command language */ if (fork() == 0) { execl(cmd, cmd, 0) } if (!background_process) retpid = wait(&status);

Example: Concurrent network server void main() { master_sockfd = sl_passivesock(port); /* create master socket */ while (TRUE) { worker_sockfd = sl_acceptsock(master_sockfd); /* await request */ switch (fork()) { case 0: /* child closes its master and manipulates worker */ close(master_sockfd); /* code to read and write to/from worker socket goes here */ exit(0); default: /* parent closes its copy of worker and repeats */ close(worker_sockfd); case -1: /* error */ fprintf("fork error\n"); }

Signals Signals Signal handlers See handout for more details. signals are software events generated by OS and processes an OS abstraction for exceptions and interrupts signals are sent from the kernel or processes to other processes. different signals are identified by small integer ID’s e.g., SIGINT: sent to foreground process when user hits ctl-c e.g., SIGALRM: sent to process when a software timer goes off the only information in a signal is its ID and the fact that it arrived. Signal handlers programs can install signal handlers for different types of signals handlers are asynchronously invoked when their signals arrive. See handout for more details.

A program that reacts to externally generated events (ctrl-c) #include <stdlib.h> #include <stdio.h> #include <signal.h> static void handler(int sig) { printf(”You think hitting ctrl-c will stop the bomb?\n"); sleep(2); printf("Well..."); fflush(stdout); sleep(1); printf("OK\n"); exit(0); } main() { signal(SIGINT, handler); /* installs ctl-c handler */ while(1) {

A program that reacts to internally generated events #include <stdio.h> #include <signal.h> int beeps = 0; /* SIGALRM handler */ void handler(int sig) { printf("BEEP\n"); fflush(stdout); if (++beeps < 5) alarm(1); else { printf("BOOM!\n"); exit(0); } main() { signal(SIGALRM, handler); alarm(1); /* send SIGALRM in 1 second */ while (1) { /* handler returns here */ } bass> a.out BEEP BOOM! bass>

Nonlocal jumps: setjmp()/longjmp() Powerful (but dangerous) user-level mechanism for transferring control to an arbitrary location. controlled to way to break the procedure stack discipline useful for error recovery int setjmp(jmp_buf j) must be called before longjmp identifies a return site for a subsequent longjmp. setjmp implementation: remember where you are by storing the current register context, stack pointer, and PC value in jmp_buf. return 0

setjmp/longjmp (cont) void longjmp(jmp_buf j, int i) meaning: return from the setjmp remembered by jump buffer j again... …this time returning i called after setjmp a function that never returns! longjmp Implementation: restore register context from jump buffer j set %eax (the return value) to i jump to the location indicated by the PC stored in jump buf j.

setjmp/longjmp example #include <setjmp.h> jmp_buf buf; main() { if (setjmp(buf) != 0) { printf(“back in main due to an error\n”); else printf(“first time through\n”); p1(); /* p1 calls p2, which calls p3 */ } ... p3() { <error checking code> if (error) longjmp(buf, 1)

Putting it all together: A program that restarts itself when ctrl-c’d #include <stdio.h> #include <signal.h> #include <setjmp.h> sigjmp_buf buf; void handler(int sig) { siglongjmp(buf, 1); } main() { signal(SIGINT, handler); if (!sigsetjmp(buf, 1)) printf("starting\n"); else printf("restarting\n"); while(1) { sleep(1); printf("processing...\n"); } bass> a.out starting processing... restarting Ctrl-c Ctrl-c Ctrl-c