1. ECE 297 Concurrent Servers Process, fork & threads ECE 297

2. Our transaction bracket Repeat get(table, key, &r) Updates to r’s values based on application logic set(table, key, r) Until No ERR_Transaction_ABORT

3. Updating versioned records in the server Receives a set(table, key, r) message Check r’s version against the version stored If there is a mismatch –Return with Transaction Abort Error Otherwise –Perform the update By incrementing the version & storing –Return success In the server

4. Our transaction bracket Repeat get(table, key, &r) Updates to r’s values based on application logic set(table, key, r) Until No ERR_Transaction_ABORT Do you see a problem with this approach to process transactions?

5. Problem After the get and before the set, the application could accidentally modify the version (or maliciously do so) Maybe update version to the version a concurrent update sequence modifies the version to Do you see a solution? –This is something to discuss in your design documents

6. ECE 297 Concurrent Servers Process, fork & threads ECE 297

7. Agenda Background on processes Creating processes (fork()) Concurrent server with fork() Background on threads Concurrent servers with threads

8. ECE 297 Background on processes

9. ECE 297 Process examples Your browser Your email reader The shell your are working in Compiler, debugger, Eclipse Word PowerPoint Your application (i.e., test cases) Your storage server, its client(s) Background

10. ECE 297 Operating system process definitions A process is a program in execution A unit of execution characterized by –A single, sequential thread of execution –A current state (registers, program counter, …) –An associated set of system resources (memory, devices, files) A unit of resource ownership (more general) In the OS processes are identified with unique IDs (process identifiers ( PID )) Sometimes also referred to as job, task, activity, … Background

11. ECE 297 Process structure A process consists of 1. An executable (i.e., code) 2. Associated data needed by the program (global data, dynamic data, shared data) 3. Execution context (or state) of the program, e.g., - Contents of data registers - Program counter, stack pointer - Memory allocation - Open file (file descriptors) code stack dynamic data data Memory Background

12. ECE 297 Process context (state) & Process Control Block Program counter CPU registers CPU scheduling information Memory management information Accounting information I/O status information Background OS manages processes as queues of PCBs

13. ECE 297 Context switch CPU switching from one process to another process is called a context switch. Execution state of running process has to be saved and execution state of next process has to be loaded (context is switched.). Time to save old and load new processes’ execution state is called context-switch time. This time is overhead ; The system does no useful work while switching. Needs to be small. Time depends on hardware support. Background

14. ECE 297 Concurrency Apparent, simultaneous execution of multiple different processes in an interleaved fashion The context switching among processes creates the illusion of processes running at the same time Given multiple cores or processors, processes may truly run in parallel Background

15. ECE 297 Process creation

16. ECE 297 Process Creation Parent processes create child processes, which in turn may create other child processes forming a tree of processes in the system –pid_t fork(void) Typically, child processes inherit parent’s resources (code, address space, memory, file descriptors etc.) –i.e., child is a duplicate of parent Sadly, but truly each child has one parent only,  Each parent may have many children If a parent dies, its children are inherited by the init process (a process created by the OS shortly after boot)

17. ECE 297 … i = fork() … A process

18. ECE 297 … i = fork() … Parent process … i = fork() … Child process Parent and child are concurrently running processes Program Counter Program Counter i = Process ID of child i = 0 !

19. ECE 297 Concurrent server

20. ECE 297 listenfd = socket(AF_INET, SOCK_STREAM, 0) … bind(listenfd, …) listen(listenfd, …) for( ; ; ){ … connfd = accept(listenfd, …); … if ( (childPID = fork()) == 0 ){ // The Child! close(listenfd); // Close listening socket do the work // Process the request exit(0); } … close(connfd); // Parent closes connfd } Concurrent server template

21. ECE 297 if ( ( childPID = fork() ) == 0 ){ this code does not execute } Child process Parent process if ( ( childPID = fork() ) == 0 ){ this code executes! }

22. ECE 297 Status of client & server I

23. ECE 297 listenfd = socket(AF_INET, SOCK_STREAM, 0) … bind(listenfd, …) listen(listenfd, …) for( ; ; ){ … connfd = accept(listenfd, …); … if ( (childPID = fork()) == 0 ){ // The Child! close(listenfd); // Close listening socket do the work // Process the request exit(0); } … close(connfd); // Parent closes connfd }

24. ECE 297 Status of client & server II

25. ECE 297 listenfd = socket(AF_INET, SOCK_STREAM, 0) … bind(listenfd, …) listen(listenfd, …) for( ; ; ){ … connfd = accept(listenfd, …); … if ( (childPID = fork()) == 0 ){ // The Child! close(listenfd); // Close listening socket do the work // Process the request exit(0); } … close(connfd); // Parent closes connfd }

26. ECE 297 Status of client & server III

27. ECE 297 listenfd = socket(AF_INET, SOCK_STREAM, 0) … bind(listenfd, …) listen(listenfd, …) for( ; ; ){ … connfd = accept(listenfd, …); … if ( (childPID = fork()) == 0 ){// The Child! close(listenfd); //Close listening socket do the work //Process the request exit(0); } … close(connfd); //Parent closes connfd } Concurrent server template

28. ECE 297 Concurrent server with fork() Basically, the template suffices to complete Milestone 4’s concurrency requirement based on process-based concurrent server Do consider caching and file access complications There are a few more complications –Zombie children –Signals –Interrupted system calls (on some OSes)

29. ECE 297 Pros & cons of fork()-based design Handles multiple connections concurrently Clean sharing model –File/socket descriptors are shared –Global variables are not shared They are carbon copies! Simple and straightforward

30. ECE 297 Pros & cons of fork()-based design Non-trivial to share data between processes Requires inter-process communication mechanisms (IPC) sockets shared memory semaphores Heavy overhead for process management (creation)