CS 3214 Computer Systems Lecture 13 Godmar Back

Announcements Project 3 milestone due Oct 8 Have still not heard from everybody regarding SVN Exercise 6 handed out CS 3214 Fall 2010

Part 1 Threads and Processes CS 3214 Fall 2010

A Context Switch Scenario Timer interrupt: P1 is preempted, context switch to P2 I/O device interrupt: P2’s I/O complete switch back to P2 Process 1 Process 2 user mode kernel mode System call: (trap): P2 starts I/O operation, blocks context switch to process 1 Timer interrupt: P2 still has time left, no context switch Kernel CS 3214 Fall 2010

Bottom Up View: 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) CS 3214 Fall 2010

Reasoning about Processes: Process States RUNNING READY BLOCKED Process must wait for event Event arrived Scheduler picks process preempted Only 1 process (per CPU) can be in RUNNING state CS 3214 Fall 2010

User View If process’s lifetimes overlap, they are said to execute concurrently Else they are sequential Default assumption is concurrently Exact execution order is unpredictable Programmer should never make any assumptions about it Any interaction between processes must be carefully synchronized CS 3214 Fall 2010

fork() #include <unistd.h> #include <stdio.h> int main() { int x = 1; if (fork() == 0) { // only child executes this printf("Child, x = %d\n", ++x); } else { // only parent executes this printf("Parent, x = %d\n", --x); } // parent and child execute this printf("Exiting with x = %d\n", x); return 0; fork() Child, x = 2 Exiting with x = 2 Parent, x = 0 Exiting with x = 0 CS 3214 Fall 2010

The fork()/join() paradigm After fork(), parent & child execute in parallel Unlike a fork in the road, here we take both roads Used in many contexts In Unix, ‘join()’ is called wait() Purpose: Launch activity that can be done in parallel & wait for its completion Or simply: launch another program and wait for its completion (shell does that) Parent: fork() Parent process executes Child process executes Child process exits Parent: join() OS notifies CS 3214 Fall 2010

fork() #include <sys/types.h> #include <unistd.h> #include <stdio.h> int main(int ac, char *av[]) { pid_t child = fork(); if (child < 0) perror(“fork”), exit(-1); if (child != 0) { printf ("I'm the parent %d, my child is %d\n", getpid(), child); wait(NULL); /* wait for child (“join”) */ } else { printf ("I'm the child %d, my parent is %d\n", getpid(), getppid()); execl("/bin/echo", "echo", "Hello, World", NULL); } CS 3214 Fall 2010

fork() vs. exec() fork(): exec(): Clone most state of parent, including memory Inherit some state, e.g. file descriptors Keeps program, changes process Called once, returns twice exec(): Overlays current process with new executable Keeps process, changes program Called once, does not return (if successful) CS 3214 Fall 2010

exit(3) vs. _exit(2) exit(3) destroys current processes OS will free resources associated with it E.g., closes file descriptors, etc. etc. Can have atexit() handlers _exit(2) skips them Exit status is stored and can be retrieved by parent Single integer Convention: exit(EXIT_SUCCESS) signals successful execution, where EXIT_SUCCESS is 0 CS 3214 Fall 2010

wait() vs waitpid() int wait(int *status) Blocks until any child exits If status != NULL, will contain value child passed to exit() Return value is the child pid Can also tell if child was abnormally terminated int waitpid(pid_t pid, int *status, int options) Can say which child to wait for CS 3214 Fall 2010

If multiple children completed, wait() returns them in arbitrary order Can use macros WIFEXITED and WEXITSTATUS to get information about exit status void fork10() { pid_t pid[N]; int i; int child_status; for (i = 0; i < N; i++) if ((pid[i] = fork()) == 0) exit(100+i); /* Child */ for (i = 0; i < N; i++) { pid_t wpid = wait(&child_status); if (WIFEXITED(child_status)) printf("Child %d terminated with exit status %d\n", wpid, WEXITSTATUS(child_status)); else printf("Child %d terminate abnormally\n", wpid); } Wait Example CS 3214 Fall 2010

Observations on fork/exit/wait Process can have many children at any point in time Establishes a parent/child relationship Resulting in a process tree Zombies: processes that have exited, but their parent hasn’t waited for them “Reaping a child process” – call wait() so that zombie’s resources can be destroyed Orphans: processes that are still alive, but whose parent has already exited (without waiting for them) Become the child of a dedicated process (“init”) who will reap them when they exit “Run Away” processes: processes that (unintentionally) execute an infinite loop and thus don’t call exit() or wait() CS 3214 Fall 2010

Unix File Descriptors Unix provides a file descriptor abstraction File descriptors are Small integers that have a local meaning within one process Can be obtained from kernel Several functions create them, e.g. open() Can refer to various kernel objects (not just files) Can be passed to a standard set of functions: read, write, close, lseek, (and more) Can be inherited when a process forks a child CS 3214 Fall 2010

Examples 0-2 are initially assigned int fd = open(“file”, O_RDONLY); 0 – stdin 1 – stdout 2 – stderr But this assignment is not fixed – process can change it via syscalls int fd = open(“file”, O_RDONLY); int fd = creat(“file”, 0600); CS 3214 Fall 2010

Implementing I/O Redirection dup and dup2() system call pipes: pipe(2) CS 3214 Fall 2010

dup2 #include <stdio.h> #include <stdlib.h> // redirect stdout to a file int main(int ac, char *av[]) { int c; int fd = creat(av[1], 0600); if (fd == -1) perror("creat"), exit(-1); if (dup2(fd, 1) == -1) perror("dup2"), exit(-1); while ((c = fgetc(stdin)) != EOF) fputc(c, stdout); } CS 3214 Fall 2010

The Big Picture user view kernel view Process 1 1 2 Terminal Device 3 1 2 Terminal Device 3 Open File File Descriptor x open(“x”) 4 File Descriptor open(“x”) close(4) Process 2 1 2 3 dup2(3,0) CS 3214 Fall 2010

Reference Counting Multiple file descriptors may refer to same open file Within the same process: fd = open(“file”); fd2 = dup(fd); Across anchestor processes: fd = open(“file”); fork(); But can also open a file multiple times: fd = open(“file”); fd2 = open(“file”); In this case, fd and fd2 have different read/write offsets In both cases, closing fd does not affect fd2 Reference Counting at 2 Levels: Kernel keeps track of how many processes refer to a file descriptor –fork() and dup() may add refs And keeps track of how many file descriptors refer to open file close(fd) removes reference in current process CS 3214 Fall 2010

Practical Implications Number of simultaneously open file descriptors per process is limited 1024 on current Linux, for instance Must make sure fd’s are closed Else ‘open()’ may fail Number space is reused “double-close” error may inadvertently close a new file descriptor assigned the same number CS 3214 Fall 2010

IPC via “pipes” Fixed Capacity Buffer write() read() A bounded buffer providing a stream of bytes flowing through Properties Writer() can put data in pipe as long as there is space If pipe() is full, writer blocks until reader reads() Reader() drains pipe() If pipe() is empty, readers blocks until writer writes Classic abstraction Decouples reader & writer Safe – no race conditions Automatically controls relative progress – if writer produces data faster than reader can read it, it blocks – and OS will likely make CPU time available to reader() to catch up. And vice versa. CS 3214 Fall 2010

pipe Note: there is no race condition in int main() { int pipe_ends[2]; if (pipe(pipe_ends) == -1) perror("pipe"), exit(-1); int child = fork(); if (child == -1) perror("fork"), exit(-1); if (child == 0) { char msg[] = { "Hi" }; close(pipe_ends[0]); write(pipe_ends[1], msg, sizeof msg); } else { char bread, pipe_buf[128]; close(pipe_ends[1]); printf("Child said "); fflush(stdout); while ((bread = read(pipe_ends[0], pipe_buf, sizeof pipe_buf)) > 0) write(1, pipe_buf, bread); } pipe Note: there is no race condition in this code. No matter what the scheduling order is, the message sent by the child will reach the parent. CS 3214 Fall 2010

esh – extensible shell Open-ended assignment Encourage collaborative learning Run each other’s plug-ins Does not mean collaboration on your implementation Secondary goals: Exposure to yacc/lex and exposure to OO-style programming in C CS 3214 Fall 2010

Using the list implementation list_entry(e, struct esh_command, elem) struct esh_pipeline: …. struct list commands struct esh_command: …. struct list_elem elem; struct list_elem *next; struct list_elem *prev; struct esh_command: …. struct list_elem elem; struct list_elem *next; struct list_elem *prev; struct list_elem head struct list_elem tail struct list_elem *next; struct list_elem *prev; struct list_elem *next; struct list_elem *prev; Key features: “list cell” – here call ‘list_elem’ is embedded in each object being kept in list Means you need 1 list_elem per list you want to keep an object in CS 3214 Fall 2010