Process and Threads

1. Process and Threads

2. Approaches to Concurrency • Processes • Hard to share resources: Easy to avoid unintended sharing • High overhead in adding/removing clients • Threads • Easy to share resources: Perhaps too easy • Medium overhead • Not much control over scheduling policies • Difficult to debug • Event orderings not repeatable • I/O Multiplexing • Tedious and low level • Total control over scheduling • Very low overhead • Cannot create as fine grained a level of concurrency • Does not make use of multi-core

3. But first, • What is a process? • Some review of the functions we learned (e.g., fork, waitpid) • What is a thread?

4. Processes • Definition: A process is an instance of a running program. • One of the most profound ideas in computer science • Not the same as “program” or “processor” • Process provides each program with two key abstractions: • Logical control flow • Each program seems to have exclusive use of the CPU • Private virtual address space • Each program seems to have exclusive use of main memory • How are these Illusions maintained? • Process executions interleaved (multitasking) or run on separate cores • Address spaces managed by virtual memory system

5. Kernel virtual memory (code, data, heap, stack) Memory invisible to user code User stack (created at runtime) %esp (stack pointer) Memory mapped region for shared libraries brk Run-time heap (created by malloc) Read/write segment (.data, .bss) Loaded from the executable file Read-only segment (.init, .text, .rodata) 0x08048000 (32) 0x00400000 (64) 0

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

7. 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

8. A View of a Process • Process = process context + code, data, and stack Process context Code, data, and stack stack SP Program context: Data registers Stack pointer (SP) Program counter (PC) Kernel context: VM structures Descriptor table brk pointer shared libraries brk run-time heap read/write data PC read-only code/data 0

9. 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 Process B user code context switch kernel code Time user code context switch kernel code user code

10. 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 • Fork is interesting (and often confusing) because it is called oncebut returns twice pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); }

11. Understanding fork Process n Child Process m pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } pid = m pid = 0 pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } pid_tpid = fork(); if (pid== 0) { printf("hello from child\n"); } else { printf("hello from parent\n"); } Which one is first? hello from parent hello from child

12. Fork Example #1 • Parent and child both run same code • Distinguish parent from child by return value from fork • Start with same state, but each has private copy • Including shared output file descriptor • Relative ordering of their print statements undefined void fork1() { int x = 1; pid_tpid = fork(); if (pid == 0) { printf("Child has x = %d\n", ++x); } else { printf("Parent has x = %d\n", --x); } printf("Bye from process %d with x = %d\n", getpid(), x); }

13. Bye L1 Bye Bye L0 L1 Bye Fork Example #2 • Both parent and child can continue forking void fork2() { printf("L0\n"); fork(); printf("L1\n"); fork(); printf("Bye\n"); }

14. Bye Bye Bye L0 L1 L2 Bye Fork Example #2 • Both parent and child can continue forking void fork4() { printf("L0\n"); if (fork() != 0) { printf("L1\n"); if (fork() != 0) { printf("L2\n"); fork(); } } printf("Bye\n"); }

15. exit: Ending a process • void exit(int status) • exits a process • Normally return with status 0 • atexit()registers functions to be executed upon exit void cleanup(void) { printf("cleaning up\n"); } void fork6() { atexit(cleanup); fork(); exit(0); }

16. File Descriptors and Descriptor Table Open file table (shared by all processes) v-node table (shared by all processes) Descriptor table (one table per process) File A stdin File access fd 0 stdout fd 1 File size File pos stderr fd 2 File type refcnt=1 fd 3 ... ... fd 4 File B File access File size File pos File type refcnt=1 ... ...

17. Open file table (shared by all processes) v-node table (shared by all processes) Descriptor tables Parent's table File A File access fd 0 fd 1 File size File pos fd 2 File type refcnt=2 fd 3 ... ... fd 4 Child's table File B File access fd 0 File size After Fork. fd 1 File pos fd 2 File type refcnt=2 fd 3 ... ... fd 4

18. Open file table (shared by all processes) v-node table (shared by all processes) Descriptor table (one table per process) File A File access fd 0 fd 1 File size File pos fd 2 File type refcnt=1 fd 3 ... ... fd 4 File B File sharing: e.g., Opening the same file twice. File pos refcnt=1 ...

19. Zombies • Idea • When process terminates, still consumes system resources • Various tables maintained by OS • Called a “zombie” • Living corpse, half alive and half dead • Reaping • Performed by parent on terminated child • Parent is given exit status information • Kernel discards process • What if parent doesn’t reap? • If any parent terminates without reaping a child, then child will be reaped by init process • So, only need explicit reaping in long-running processes • e.g., shells and servers

20. Zombie Example void fork7() { if (fork() == 0) { /* Child */ printf("Terminating Child, PID = %d\n", getpid()); exit(0); } else { printf("Running Parent, PID = %d\n", getpid()); while (1) ; /* Infinite loop */ } } • ps shows child process as “defunct” • Killing parent allows child to be reaped by init linux> ./forks 7 & [1] 6639 Running Parent, PID = 6639 Terminating Child, PID = 6640 linux> ps PID TTY TIME CMD 6585 ttyp9 00:00:00 tcsh 6639 ttyp9 00:00:03 forks 6640 ttyp9 00:00:00 forks <defunct> 6641 ttyp9 00:00:00 ps linux> kill 6639 [1] Terminated linux> ps PID TTY TIME CMD 6585 ttyp9 00:00:00 tcsh 6642 ttyp9 00:00:00 ps

21. wait: Synchronizing with Children • int wait(int *child_status) • suspends current process until one of its children terminates • return value is 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

22. HC Bye HP CT Bye wait: Synchronizing with Children void fork9() { int child_status; if (fork() == 0) { printf("HC: hello from child\n"); } else { printf("HP: hello from parent\n"); wait(&child_status); printf("CT: child has terminated\n"); } printf("Bye\n"); exit(); }

23. wait() Example • 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); } }

24. waitpid(): Waiting for a Specific Process • waitpid(pid, &status, options) • suspends current process until specific process terminate void fork11() { 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 = N-1; i >= 0; i--) { pid_t wpid = waitpid(pid[i], &child_status, 0); if (WIFEXITED(child_status)) printf("Child %d terminated with exit status %d\n", wpid, WEXITSTATUS(child_status)); else printf("Child %d terminated abnormally\n", wpid); } }

25. Summary • Processes • At any given time, system has multiple active processes • Only one can execute at a time on a single core, though • Each process appears to have total control of processor + private memory space

26. Summary (cont.) • Spawning processes • Call fork • One call, two returns • Process completion • Call exit • One call, no return • Reaping and waiting for Processes • Call wait or waitpid

27. Approaches to Concurrency • Processes • Hard to share resources: Easy to avoid unintended sharing • High overhead in adding/removing clients • Threads • Easy to share resources: Perhaps too easy • Medium overhead • Not much control over scheduling policies • Difficult to debug • Event orderings not repeatable • I/O Multiplexing • Tedious and low level • Total control over scheduling • Very low overhead • Cannot create as fine grained a level of concurrency • Does not make use of multi-core

28. Approach #3: Multiple Threads • Very similar to approach #1 (multiple processes) • but, with threads instead of processes

29. Traditional View of a Process • Process = process context + code, data, and stack Process context Code, data, and stack stack SP Program context: Data registers Condition codes Stack pointer (SP) Program counter (PC) Kernel context: VM structures Descriptor table brk pointer shared libraries brk run-time heap read/write data PC read-only code/data 0

30. Alternate View of a Process • Process = thread + code, data, and kernel context Thread (main thread) Code and Data shared libraries stack brk SP run-time heap read/write data Thread context: Data registers Condition codes Stack pointer (SP) Program counter (PC) PC read-only code/data 0 Kernel context: VM structures Descriptor table brk pointer

31. A Process With Multiple Threads • Multiple threads can be associated with a process • Each thread has its own logical control flow • Each thread shares the same code, data, and kernel context • Share common virtual address space (inc. stacks) • Each thread has its own thread id (TID) Shared code and data Thread 2 (peer thread) Thread 1 (main thread) shared libraries stack 1 stack 2 run-time heap read/write data Thread 1 context: Data registers Condition codes SP1 PC1 Thread 2 context: Data registers Condition codes SP2 PC2 read-only code/data 0 Kernel context: VM structures Descriptor table brkpointer

32. Logical View of Threads • Threads associated with process form a pool of peers • Unlike processes which form a tree hierarchy Threads associated with process foo Process hierarchy P0 T2 T4 T1 P1 shared code, data and kernel context sh sh sh T3 T5 foo bar

33. Thread Execution • Single Core Processor • Simulate concurrency by time slicing • Multi-Core Processor • Can have true concurrency Thread A Thread B Thread C Thread A Thread B Thread C Time Run 3 threads on 2 cores

34. Logical Concurrency • Two threads are (logically) concurrent if their flows overlap in time • Otherwise, they are sequential • Examples: • Concurrent: A & B, A&C • Sequential: B & C Thread A Thread B Thread C Time

35. Threads vs. Processes • How threads and processes are similar • Each has its own logical control flow • Each can run concurrently with others (possibly on different cores) • Each is context switched • How threads and processes are different • Threads share code and some data • Processes (typically) do not • Threads are somewhat less expensive than processes • Process control (creating and reaping) is twice as expensive as thread control • Linux numbers: • ~20K cycles to create and reap a process • ~10K cycles (or less) to create and reap a thread

36. Posix Threads (Pthreads) Interface • Pthreads: Standard interface for ~60 functions that manipulate threads from C programs • Creating and reaping threads • pthread_create() • pthread_join() • Determining your thread ID • pthread_self() • Terminating threads • pthread_cancel() • pthread_exit() • exit() [terminates all threads] , RET [terminates current thread] • Synchronizing access to shared variables • pthread_mutex_init • pthread_mutex_[un]lock • pthread_cond_init • pthread_cond_[timed]wait

37. The Pthreads "hello, world" Program /* * hello.c - Pthreads "hello, world" program */ #include "csapp.h" void *thread(void *vargp); int main() { pthread_ttid; Pthread_create(&tid, NULL, thread, NULL); Pthread_join(tid, NULL); exit(0); } Thread attributes (usually NULL) Thread arguments (void *p) return value (void **p) /* thread routine */ void *thread(void *vargp) { printf("Hello, world!\n"); return NULL; }

38. Execution of Threaded“hello, world” main thread call Pthread_create() Pthread_create() returns peer thread call Pthread_join() printf() main thread waits for peer thread to terminate return NULL; (peer thread terminates) Pthread_join() returns exit() terminates main thread and any peer threads

39. Thread-Based Concurrent Echo Server • Spawn new thread for each client • Pass it copy of connection file descriptor • Note use of Malloc()! • Without corresponding Free() int main(intargc, char **argv) { int port = atoi(argv[1]); structsockaddr_inclientaddr; intclientlen=sizeof(clientaddr); pthread_ttid; intlistenfd = Open_listenfd(port); while (1) { int *connfdp = Malloc(sizeof(int)); *connfdp = Accept(listenfd, (SA *) &clientaddr, &clientlen); Pthread_create(&tid, NULL, echo_thread, connfdp); } }

40. Thread-Based Concurrent Server (cont) /* thread routine */ void *echo_thread(void *vargp) { intconnfd = *((int *)vargp); Pthread_detach(pthread_self()); Free(vargp); echo(connfd); Close(connfd); return NULL; } • Run thread in “detached” mode • Runs independently of other threads • Reaped when it terminates • Free storage allocated to hold clientfd • “Producer-Consumer” model

41. Threaded Execution Model • Multiple threads within single process • Some state between them • File descriptors Connection Requests Listening Server Client 2 Server Client 1 Server Client 1 data Client 2 data

42. Potential Form of Unintended Sharing while (1) { intconnfd = Accept(listenfd, (SA *) &clientaddr, &clientlen); Pthread_create(&tid, NULL, echo_thread, (void *) &connfd); } } main thread Main thread stack connfd connfd = connfd1 peer1 Peer1 stack vargp connfd = *vargp connfd = connfd2 Race! peer2 Peer2 stack connfd = *vargp vargp Why would both copies of vargp point to same location?

43. Could this race occur? Main Thread • Race Test • If no race, then each thread would get different value of i • Set of saved values would consist of one copy each of 0 through 99. inti; for (i = 0; i < 100; i++) { Pthread_create(&tid, NULL, thread, &i); } void *thread(void *vargp) { inti = *((int *)vargp); Pthread_detach(pthread_self()); save_value(i); return NULL; }

44. Experimental Results No Race • The race can really happen! Single core laptop Multicore server

45. Issues With Thread-Based Servers • Must run “detached” to avoid memory leak. • At any point in time, a thread is either joinable or detached. • Joinable thread can be reaped and killed by other threads. • must be reaped (with pthread_join) to free memory resources. • Detached thread cannot be reaped or killed by other threads. • resources are automatically reaped on termination. • Default state is joinable. • use pthread_detach(pthread_self()) to make detached. • Must be careful to avoid unintended sharing. • For example, passing pointer to main thread’s stack Pthread_create(&tid, NULL, thread, (void *)&connfd); • All functions called by a thread must be thread-safe • Stay tuned

46. Pros and Cons of Thread-Based Designs • + Easy to share data structures between threads • e.g., logging information, file cache. • + Threads are more efficient than processes. • –Unintentional sharing can introduce subtle and hard-to-reproduce errors! • The ease with which data can be shared is both the greatest strength and the greatest weakness of threads. • Hard to know which data shared & which private • Hard to detect by testing • Probability of bad race outcome very low • But nonzero! • Future lectures