1. Userland summary Nezer J. Zaidenberg

2. Today’s topics What have we learned - USERLAND summary Revisited topics execXXX functions POSIX cond Sync methods we learned EX 2 Pseudo code What have we learned - USERLAND summary Revisited topics execXXX functions POSIX cond Sync methods we learned EX 2 Pseudo code

3. Topics we covered - Processes We learned how to create process (fork(2)) execute a run time (execXXX(2)) How to wait(2) and waitpid(2) for process We tried 2 methods of Inter process communications IPC (network and UNIX domain sockets) - THERE ARE MANY MORE We understand process environment - File descriptor table, environment (getenv(2)), heap, stack, global variables Daemon process Signals (sigaction(2)/signal(3)) We learned how to create process (fork(2)) execute a run time (execXXX(2)) How to wait(2) and waitpid(2) for process We tried 2 methods of Inter process communications IPC (network and UNIX domain sockets) - THERE ARE MANY MORE We understand process environment - File descriptor table, environment (getenv(2)), heap, stack, global variables Daemon process Signals (sigaction(2)/signal(3))

4. Topics we covered - Threads We learned to create POSIX threads We learned to join threads We learned to sync threads using POSIX cond POSIX mutex We know what re-enterant and non-reenterant function is (strtok(3) and strtok_r(3)) We discussed (in lecture) some syncing algorithms We learned to create POSIX threads We learned to join threads We learned to sync threads using POSIX cond POSIX mutex We know what re-enterant and non-reenterant function is (strtok(3) and strtok_r(3)) We discussed (in lecture) some syncing algorithms

5. Topics we covered - Files We know what file descriptor is (and to dup(2) it) We know how to open(2) and close(2) fd We know how to read(2) write(2) and lseek(2) files We know how to stat(2) to get file info We know how to unlink(2) to delete file or UDS. We know how to mmap(2) munmap(2) and msync(2) files We also know open/scan/readdir(2) API We know what file descriptor is (and to dup(2) it) We know how to open(2) and close(2) fd We know how to read(2) write(2) and lseek(2) files We know how to stat(2) to get file info We know how to unlink(2) to delete file or UDS. We know how to mmap(2) munmap(2) and msync(2) files We also know open/scan/readdir(2) API

6. Topics we covered - networking Behavior of AF_INET, AF_UNIX SOCK_STREAM, SOCK_DGRAM socket(2), bind(2), listen(2),accept(2), connect(2), send(2), recv(2), close(2) and shutdown(2) sendto(2) and recvfrom(2) select(2) Behavior of AF_INET, AF_UNIX SOCK_STREAM, SOCK_DGRAM socket(2), bind(2), listen(2),accept(2), connect(2), send(2), recv(2), close(2) and shutdown(2) sendto(2) and recvfrom(2) select(2)

7. Topics we covered UNIX At this point I assume you all know how to Edit a file Compile a project Create make file Run user commands efficiently Read a manpage Get the unix time(2) Hopefully you should also be able to Debug you code Generate core dump and process it Run strace(1) on a running server and see what’s up At this point I assume you all know how to Edit a file Compile a project Create make file Run user commands efficiently Read a manpage Get the unix time(2) Hopefully you should also be able to Debug you code Generate core dump and process it Run strace(1) on a running server and see what’s up

8. Revisited topics - execXXX Refs 8.9 in APUE 1st edition (p 207-212) 8.10 in APUE 2nd edition (p 231-237) Family of 6 functions (execlp, execvp, execv, execl, execve, execle) execve is the most generic (lowest layer) Those function replace the running image of the current process with new one Refs 8.9 in APUE 1st edition (p 207-212) 8.10 in APUE 2nd edition (p 231-237) Family of 6 functions (execlp, execvp, execv, execl, execve, execle) execve is the most generic (lowest layer) Those function replace the running image of the current process with new one

9. Exec functions Suffixes The function with l suffix builds argv The functions with the e suffix allow to change environ The functions with the p suffix try each path in PATH environment variable (so if we run ls it will find /bin/ls) Suffixes The function with l suffix builds argv The functions with the e suffix allow to change environ The functions with the p suffix try each path in PATH environment variable (so if we run ls it will find /bin/ls)

10. Exec functions What does replace the current process image means? The process has it’s memory space (data and program itself) released. Instead a new program is loaded. When the new program terminates the process terminates. There is no way to get back to the old program or to get its data Though it is by no means a must typical use of exec involves a call to fork(2) and wait(2) This is the way your shell (bash(1) or tcsh(1)) calls your programs What does replace the current process image means? The process has it’s memory space (data and program itself) released. Instead a new program is loaded. When the new program terminates the process terminates. There is no way to get back to the old program or to get its data Though it is by no means a must typical use of exec involves a call to fork(2) and wait(2) This is the way your shell (bash(1) or tcsh(1)) calls your programs

11. System(3) - exec example // system(3) is function that runs another program … smt like int my_system (const char *command) { int pid, status; if (command == 0) return 1; pid = fork(); if (pid == -1) return -1; if (pid == 0) { char *argv[4]; argv[0] = "sh"; argv[1] = "-c"; argv[2] = command; argv[3] = 0; execve("/bin/sh", argv, environ); exit(127); // This code will be reached only if execve has problems // system(3) is function that runs another program … smt like int my_system (const char *command) { int pid, status; if (command == 0) return 1; pid = fork(); if (pid == -1) return -1; if (pid == 0) { char *argv[4]; argv[0] = "sh"; argv[1] = "-c"; argv[2] = command; argv[3] = 0; execve("/bin/sh", argv, environ); exit(127); // This code will be reached only if execve has problems

12. System (cont’d) } do { if (waitpid(pid, &status, 0) == -1) { if (errno != EINTR) return -1; } else return status; } while(1); } // Note that system(3) is not very recommended function and I prefer you will use the above // instead of system(3) in your homework (but using system is legal) // the above code is from the BUGS section of man system. It is suggested as replacement // I suggest you follow the advice } do { if (waitpid(pid, &status, 0) == -1) { if (errno != EINTR) return -1; } else return status; } while(1); } // Note that system(3) is not very recommended function and I prefer you will use the above // instead of system(3) in your homework (but using system is legal) // the above code is from the BUGS section of man system. It is suggested as replacement // I suggest you follow the advice

13. POSIX cond Ref : APUE 2nd edition (doesn’t appear on first) 11.6 (specifically p 382-385) We know of mutex - I came first therefore it is mine. But lets think of the following scenarios (hint - homework 2) I have a file being received and I need to compress it/uncompress it when receiving is done I have a file being compressed. I have to wake up some threads that will send the file but only after compression is done Ref : APUE 2nd edition (doesn’t appear on first) 11.6 (specifically p 382-385) We know of mutex - I came first therefore it is mine. But lets think of the following scenarios (hint - homework 2) I have a file being received and I need to compress it/uncompress it when receiving is done I have a file being compressed. I have to wake up some threads that will send the file but only after compression is done

14. Cond Vs. Mutex In Mutex case I am entering the critical section AND prevent other threads from entering there. In cond case I am blocking myself from entering the critical section. I release myself after another thread has finished preparing the critical section for me In Mutex case I am entering the critical section AND prevent other threads from entering there. In cond case I am blocking myself from entering the critical section. I release myself after another thread has finished preparing the critical section for me

15. Cond example check out p384-385 of APUE 2e for a simpler example but their code is not a complete program In our example we will wait for child process to die. (that child process may have done some work for us… such as compress or uncompress file) then we wake up another thread when we are done check out p384-385 of APUE 2e for a simpler example but their code is not a complete program In our example we will wait for child process to die. (that child process may have done some work for us… such as compress or uncompress file) then we wake up another thread when we are done

16. Cond example - singal when child die pthread_cond_t readycond=PTHREAD_COND_INITIALIZER; pthread_mutex_t readymutex=PTHREAD_MUTEX_INIALIZER; void * waitingThread(void * arg) { pthread_mutex_lock(&readymutex); printf (“before waiting for cond\n”); pthread_cond_wait(&readycond); printf (“after cond was relesaed\n); // do something } pthread_cond_t readycond=PTHREAD_COND_INITIALIZER; pthread_mutex_t readymutex=PTHREAD_MUTEX_INIALIZER; void * waitingThread(void * arg) { pthread_mutex_lock(&readymutex); printf (“before waiting for cond\n”); pthread_cond_wait(&readycond); printf (“after cond was relesaed\n); // do something }

17. Cond example 2/2 Int main() { pthread_t tid; pthread_create(&tid,NULL,waitingThread,NULL); my_system(getenv(“program”)); // my_system from slide 11- 12. Regular notes regarding return codes pthread_cond_signal(&readycond); sleep(5); // do something so that we will not fall from main() } Int main() { pthread_t tid; pthread_create(&tid,NULL,waitingThread,NULL); my_system(getenv(“program”)); // my_system from slide 11- 12. Regular notes regarding return codes pthread_cond_signal(&readycond); sleep(5); // do something so that we will not fall from main() }

18. Cond function prototypes #include int pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *attr); int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex); int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime); #include int pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *attr); int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex); int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);

19. Cond function prototypes 2/2 #include int pthread_cond_signal(pthread_cond_t *cond); int pthread_cond_broadcast(pthread_cond_t *cond); int pthread_cond_destroy(pthread_cond_t *cond); #include int pthread_cond_signal(pthread_cond_t *cond); int pthread_cond_broadcast(pthread_cond_t *cond); int pthread_cond_destroy(pthread_cond_t *cond);

20. Initializing conds and mutexes Can be done using the constant (PTHREAD_COND_INITIALIZER, PTHREAD_MUTEX_INITIALIZER) Or using the functions (pthread_mutex_init(2), pthread_cond_init(2)) Unless you know better it is quite safe to give null for attributes. Cond and mutex attributes are discussed in 12.4 of APUE 2e and refer to things such as is the mutex recursive (i.e. if it is locked twice, by the same thread does it have to be released twice) Most attributes (with the exception of recursive mutex) are beyond the scope for us. Can be done using the constant (PTHREAD_COND_INITIALIZER, PTHREAD_MUTEX_INITIALIZER) Or using the functions (pthread_mutex_init(2), pthread_cond_init(2)) Unless you know better it is quite safe to give null for attributes. Cond and mutex attributes are discussed in 12.4 of APUE 2e and refer to things such as is the mutex recursive (i.e. if it is locked twice, by the same thread does it have to be released twice) Most attributes (with the exception of recursive mutex) are beyond the scope for us.

21. Syncing methods For processes We can use file locking to implement mutex We use IPC (for example UDS) to implement cond - I.e. we send one byte when we are ready. We select-wait for that byte in similar way to cond. (this also works between threads) For processes We can use file locking to implement mutex We use IPC (for example UDS) to implement cond - I.e. we send one byte when we are ready. We select-wait for that byte in similar way to cond. (this also works between threads) For threads We use mutex to lock critical section We use cond to lock ourselves Those mechanisms do not work on Processes! (we cannot lock a thread that belongs to a different process using those devices!)

22. Ex 2 - pseudo code This is just ment to assist some student that are stack if you have your own implementation that work you do not have to follow those guidelines This assumes that we don’t support libbz2 or multiple clients This is just ment to assist some student that are stack if you have your own implementation that work you do not have to follow those guidelines This assumes that we don’t support libbz2 or multiple clients

23. Protocol We will specify in each packet the index and the number of packets (server knows the size of packet received) The protocol assumes fixed packet size for calculation of offset. (I.e. all packets, except for last are of the same size) We will specify in each packet the index and the number of packets (server knows the size of packet received) The protocol assumes fixed packet size for calculation of offset. (I.e. all packets, except for last are of the same size)

24. Server - main thread Start 10 handling threads Fnctl lock temporary file Socket/bind UDS datagram socket Start 10 handling threads Fnctl lock temporary file Socket/bind UDS datagram socket

25. Server mainthread cont While (file not completely received()) Select-recvfrom next packet // on first packet we must // save client UDS // record packet size // possible - handle special case first = last Unlock the file While (file not completely received()) Select-recvfrom next packet // on first packet we must // save client UDS // record packet size // possible - handle special case first = last Unlock the file

26. Server mainthread - cont Fork/exec/wait for bzip Write compressed file name in shared memory. Send signal to all waiting threads cond (either via loop and pthread_cond_signal or via pthread_cond_broadcast) Fork/exec/wait for bzip Write compressed file name in shared memory. Send signal to all waiting threads cond (either via loop and pthread_cond_signal or via pthread_cond_broadcast)

27. Client main thread Start recv thread // (select/recvfrom message on socket) Start 10 connection handling thread. Wait for signal on cond (decompression completed) Compare files (using memcmp) Start recv thread // (select/recvfrom message on socket) Start 10 connection handling thread. Wait for signal on cond (decompression completed) Compare files (using memcmp)

28. Client recv thread // Similar to server but Send signal to main thread cond once file recv is completed. While (file not completely received()) Select-recvfrom next packet // on first packet we must // save client UDS // record packet size // possible - handle special case first = last Send signal // Similar to server but Send signal to main thread cond once file recv is completed. While (file not completely received()) Select-recvfrom next packet // on first packet we must // save client UDS // record packet size // possible - handle special case first = last Send signal

29. Connection handling thread // it is assumed that filename is known (for example temp.bz2 in server and getenv( “ filename ” ) in client // I have implemented socket per connection you may // want just one socket to be shared among all threads 1. socket(2) 2. wait for cond() // only for server!!!! // wake me up when the compressed file is ready 3. read compressed file name() // it is assumed that filename is known (for example temp.bz2 in server and getenv( “ filename ” ) in client // I have implemented socket per connection you may // want just one socket to be shared among all threads 1. socket(2) 2. wait for cond() // only for server!!!! // wake me up when the compressed file is ready 3. read compressed file name()

30. Connection handling thread 4. while (file not finished) 5. { 6. read next chunk() 7. get packet number() // or offset 8. unlock() 9. create packet() // what you will send will include last packet/file size indication and offset/packet number 10. send packet via my socket() 11.} // pthread can exit/join now 4. while (file not finished) 5. { 6. read next chunk() 7. get packet number() // or offset 8. unlock() 9. create packet() // what you will send will include last packet/file size indication and offset/packet number 10. send packet via my socket() 11.} // pthread can exit/join now

31. Things to note USE of Threads Mmap/munmap/msync Open/Read/write/lseek/close Conds and mutexes Fcntl locking Execv/fork/wait YES I KNOW YOU CAN DO WITHOUT BUT I WANT YOU TO USE THEM! USE of Threads Mmap/munmap/msync Open/Read/write/lseek/close Conds and mutexes Fcntl locking Execv/fork/wait YES I KNOW YOU CAN DO WITHOUT BUT I WANT YOU TO USE THEM!

32. Things to note Make sure that the file received after uncompressing is identical to the file sent (We will send large random files make sure you get it right!) Make sure you sync! Assume filesize >> packetsize so each connection thread on average will send more then 1 packet Don’t assume file is text and don’t use any strXXX functions on the file (the file may have nulls in it) DON’T SUBMIT EX THAT DON”T RUN OR THAT DON”T RETURN MATCHING FILES Make sure that the file received after uncompressing is identical to the file sent (We will send large random files make sure you get it right!) Make sure you sync! Assume filesize >> packetsize so each connection thread on average will send more then 1 packet Don’t assume file is text and don’t use any strXXX functions on the file (the file may have nulls in it) DON’T SUBMIT EX THAT DON”T RUN OR THAT DON”T RETURN MATCHING FILES

33. Syncing pitfalls Problem 1 Thread 1 reads packet Thread 2 reads same packet Thread 1 names this packet 1 Thread 2 names this packet 2 Problem 2 Thread 1 reads packet Thread 2 reads next packet Thread 1 names his packet packet 1 Thread 2 names his packet packet 1 Problem 1 Thread 1 reads packet Thread 2 reads same packet Thread 1 names this packet 1 Thread 2 names this packet 2 Problem 2 Thread 1 reads packet Thread 2 reads next packet Thread 1 names his packet packet 1 Thread 2 names his packet packet 1

34. More pitfalls Packet 100 is last and arrived. You send signal But packet 99 is not yet arrived. *(you compress/uncompress garbage)* You receive packets from two clients but the packets mix…. Packet 100 is last and arrived. You send signal But packet 99 is not yet arrived. *(you compress/uncompress garbage)* You receive packets from two clients but the packets mix….

35. Supporting many clients Requires coding and planning. Build server that support one client, test it, then modify don’t start with the multiple client problem because you may run into problems and fail to finish at all

36. Using libbz2 Is actually up to you as a “learn-it-yourself” project. (don’t come to me with questions :-)) You are exempt from using exec (because you never exec bzip) If you are using ANY temp file in the server you must demonstrate locking. If you manage to do everything without any temp file you are exempt from locking Take note that you may still be asked regarding execv and fcntl on the test Is actually up to you as a “learn-it-yourself” project. (don’t come to me with questions :-)) You are exempt from using exec (because you never exec bzip) If you are using ANY temp file in the server you must demonstrate locking. If you manage to do everything without any temp file you are exempt from locking Take note that you may still be asked regarding execv and fcntl on the test

37. Starting next week we study kernel (AT LAST!)