CS 3214 Computer Systems Godmar Back Lecture 12

Announcements Exercise 6 coming up Project 3 milestone due Oct 8 CS 3214 Fall 2010

THREADS AND PROCESSES Part 1 CS 3214 Fall 2010

Processes Def: An instance of a program in execution OS provides each process with key abstractions –Logical control flow 1 flow – single-threaded process Multiple flows – multi-threaded process –Private address space –Abstracted resources: e.g., stdout/stdin file descriptors These abstractions create the illusion that each process has access to its own –CPU (or CPUs for multi-threaded processes) –Memory –Devices: e.g., terminal CS 3214 Fall 2010

Context Switching Historical motivation for processes was introduction of multi-programming: –Load multiple processes into memory, and switch to another process if current process is (momentarily) blocked –This required protection and isolation between these processes, implemented by a privileged kernel Time-sharing: switch to another process periodically to make sure all processes make equal progress Switch between processes is called a context switch CS 3214 Fall 2010

Dual-Mode Operation Two fundamental modes: –“kernel mode” – privileged aka system, supervisor or monitor mode Intel calls its PL0, Privilege Level 0 on x86 –“user mode” – non-privileged PL3 on x86 Bit in CPU – controls operation of CPU –Privileged operations can only be performed in kernel mode. Example: hlt –Must carefully control transition between user & kernel mode int main() { asm(“hlt”); } int main() { asm(“hlt”); }

Mode Switching User  Kernel mode –For reasons external or internal to CPU External (aka hardware) interrupt: –timer/clock chip, I/O device, network card, keyboard, mouse –asynchronous (with respect to the executing program) Internal interrupt (aka software interrupt, trap, or exception) –are synchronous –can be intended (“trap”): for system call (process wants to enter kernel to obtain services) –or unintended (usually): (“fault/exception”) (division by zero, attempt to execute privileged instruction in user mode, memory access violation, invalid instruction, alignment error, etc.) Kernel  User mode switch on iret instruction CS 3214 Fall 2010

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

CS 3214 Fall 2010 Context Switching, Details Process 1 Process 2 Kernel user mode kernel mode intr_entry: (saves entire CPU state) (switches to kernel stack) intr_entry: (saves entire CPU state) (switches to kernel stack) intr_exit: (restore entire CPU state) (switch back to user stack) iret intr_exit: (restore entire CPU state) (switch back to user stack) iret switch_threads: (in) (saves caller’s state) switch_threads: (in) (saves caller’s state) switch_threads: (out) (restores caller’s state) switch_threads: (out) (restores caller’s state) (kernel stack switch)

CS 3214 Fall 2010 System Calls Process 1 Kernel user mode kernel mode User processes access kernel services by trapping into the kernel, executing kernel code to perform the service, then returning – very much like a library call. Unless the system call cannot complete immediately, this does not involve a context switch. Kernel’s System Call Implementation

Syscall example: write(2) CS 3214 Fall 2010 /* gcc -static -O -g -Wall write.c -o write */ #include int main() { const char msg[] = "Hello, World\n"; return write(1, msg, sizeof msg); } /* gcc -static -O -g -Wall write.c -o write */ #include int main() { const char msg[] = "Hello, World\n"; return write(1, msg, sizeof msg); } a : a: 53 push %ebx b: 8b mov 0x10(%esp),%edx #arg f: 8b 4c 24 0c mov 0xc(%esp),%ecx # arg : 8b 5c mov 0x8(%esp),%ebx # arg : b mov $0x4,%eax # syscall no c: cd 80 int $0x e: 5b pop %ebx f: 3d 01 f0 ff ff cmp $0xfffff001,%eax : 0f e jae 8051ed a: c3 ret a : a: 53 push %ebx b: 8b mov 0x10(%esp),%edx #arg f: 8b 4c 24 0c mov 0xc(%esp),%ecx # arg : 8b 5c mov 0x8(%esp),%ebx # arg : b mov $0x4,%eax # syscall no c: cd 80 int $0x e: 5b pop %ebx f: 3d 01 f0 ff ff cmp $0xfffff001,%eax : 0f e jae 8051ed a: c3 ret /usr/include/asm/unistd.h: …. #define __NR_write 4 ….

CS 3214 Fall 2010 Kernel Threads Process 1 Process 2 Kernel user mode kernel mode Most OS support kernel threads that never run in user mode – these threads typically perform book keeping or other supporting tasks. They do not service system calls or faults. Most OS support kernel threads that never run in user mode – these threads typically perform book keeping or other supporting tasks. They do not service system calls or faults. Kernel Thread Careful: “kernel thread” not the same as kernel-level thread (KLT) – more on KLT later

Context vs Mode Switching Mode switch guarantees kernel gains control when needed –To react to external events –To handle error situations –Entry into kernel is controlled Not all mode switches lead to context switches –Kernel decides when – subject of scheduling policies Mode switch does not change the identity of current process/thread –See blue/yellow colors in slide on ctxt switch details Hardware knows about modes, does not (typically) know about contexts CS 3214 Fall 2010

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

Process States RUNNING: –Process is on CPU, its instructions are executed READY: –Process could make progress if a CPU were available BLOCKED: –Process cannot make progress even if a CPU were available because it’s waiting for something (e.g., a resource, a signal, a point in time, …) Model is simplified –OS have between 5 and 10 states typically Terminology not consistent across OS: –E.g., Linux calls BLOCKED “SLEEPING” and READY “RUNNING” 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

Process Creation Two common paradigms: –Cloning vs. spawning Cloning: (Unix) –“fork()” clones current process –child process then loads new program Spawning: (Windows) –“exec()” spawns a new process with new program Difference is whether creation of new process also involves a change in program

CS 3214 Fall 2010 fork() #include 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; } #include 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; } 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: fork() Parent: join() Parent process executes Parent process executes Child process executes Child process executes Child process exits Child process exits OS notifies

CS 3214 Fall 2010 fork() #include 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); } #include 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); }

fork() vs. exec() fork(): –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, will take 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