2.3 InterProcess Communication (IPC)

1. 2.3 InterProcess Communication (IPC)

2. IPC methods • Signals • Mutex (MUTual EXclusion) • Semaphores • Shared memory • Memory mapped files • Pipes & named pipes • Sockets • Message queues • MPI (Message Passing Interface) • Barriers

3. IPC methods thread to thread process to process (both on same system) system to system (i.e., processes on different systems)

4. IPC methods between threads • Mutex • Semaphores

5. IPC methods between processes • Signals • Shared memory • Memory mapped files • Pipes & named pipes • Message queues

6. IPC methods between systems • Sockets • MPI (Message Passing Interface) • Barriers

7. Signals

8. Signals • software interrupts • async • can be recognized or ignored

9. Signals #include <signal.h> //defn. of signal handler function typedef void (*sighandler_t)(int); //function call to establish a signal handler sighandler_t signal ( int signum, sighandler_t handler ); What is this?

10. Remember . . . char* ptr1, ptr2; is not the same as char* ptr1; char* ptr2; It really means char *ptr1, ptr2; Use char *ptr1, *ptr2; instead.

11. Allowed signals (see kill –l) 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 32) SIGRTMIN 33) SIGRTMIN+1 34) SIGRTMIN+2 35) SIGRTMIN+3 36) SIGRTMIN+4 37) SIGRTMIN+5 38) SIGRTMIN+6 39) SIGRTMIN+7 40) SIGRTMIN+8 41) SIGRTMIN+9 42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13 46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14 50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10 54) SIGRTMAX-9 55) SIGRTMAX-8 56) SIGRTMAX-7 57) SIGRTMAX-6 58) SIGRTMAX-5 59) SIGRTMAX-4 60) SIGRTMAX-3 61) SIGRTMAX-2 62) SIGRTMAX-1 63) SIGRTMAX • Also see man 7 signal for a lengthier description.

12. As reported by kill -l on SunOS/Solaris (Sun’s Unix) • HUP, INT, QUIT, ILL, TRAP, ABRT, EMT, FPE, KILL, BUS, SEGV, SYS, PIPE, ALRM, TERM, USR1, USR2, CLD, PWR, WINCH, URG, POLL, STOP, TSTP, CONT, TTIN, TTOU, VTALRM, PROF, XCPU, XFSZ, WAITING, LWP, FREEZE, THAW, CANCEL, LOST, XRES, JVM1, JVM2, RTMIN, RTMIN+1, RTMIN+2, RTMIN+3, RTMAX-3, RTMAX-2, RTMAX-1, RTMAX

13. Sending a signal to a process • Use the kill command (see man kill). • kill [ -s signal | -p ] [ -a ] [ -- ] pid ... • kill -l [ signal ] • Use the kill function (see man 2 kill) #include <sys/types.h> #include <signal.h> int kill ( pid_t pid, int sig );

14. Signal example code //define the signal hander function void myHandler ( int signalNo ) { … } … //define the signal handler // (typically done once in main) signal( SIGCHLD, myHandler );

15. Mutex Used to control access to shared memory and other resources, in general.

16. Race condition • An error where • one process may wait forever • or other inconsistencies may result • Occurs when two or more processes are reading or writing some shared data • Applies to threads as well • The final result depends on process or thread runs, precisely when they run, and in what order they run. • Difficult to debug and reproduce errors.

17. Critical region/section • Part of program where shared memory is accessed • Must be identified • mutual exclusion (mutex) • method to exclude other processes from using a shared variable until our process is finished with it

18. Process cooperation rules: • No two processes can be in their critical sections at the same time. • Make no timing assumptions. • My code is faster/shorter; my processor is faster. • My priority is higher. • The probability is small for us both processes to do this at the same time. • (progress) A process should not be blocked from entering a critical region if all other processes are outside the critical region. • (bounded wait) No process should have to wait forever to get into its critical region.

19. Mutual exclusion w/ busy waiting Methods to implement mutex: • Disable interrupts • Lock variables • Strict alternation • Peterson’s solution • TSL instruction

20. Mutex method 1: disable interrupts • OK for (and used by) OS • Consideration for MP systems • NOT OK for apps • Why not?

21. Mutex method 2: lock vars • software method • employs single, shared lock variable initially = 0 • uses busy wait  spin lock

22. Mutex method 2: lock vars shared int x=0; //wait for lock while (x!=0) ; // note the empty statement x=1; //get lock //critical section … //end critical section x=0; //release lock • Doesn’t work (w/out hardware support). • What about performance?

23. Mutex method 3: strict alternation

24. Mutex method 3: strict alternation • Software • Problem: violates process cooperation rule #3. • Because in strict alternation, a process can be blocked from entering its C.S. by a process NOT in its C.S. • In general, a process can’t be in it’s C.S. 2x in a row. • The 2 processes must be running at about the same speed.

25. Mutex method 4: Peterson’s (sofware) soln.

26. Mutex method 4: Peterson’s (software) soln.

27. Mutex method 4: Peterson’s soln. (software)

28. Mutex method 4: Peterson’s (sofware) soln. • Works, but suffers from busy wait. • Has been generalized to more than 2 processes (but the above is only for 2).

29. Mutex method 5: TSL instruction • TSL = Test and Set Locked • TSL RX, LOCK • RX = register; LOCK = memory location • Step 1: read contents of LOCK into RX • Step 2: sets LOCK to 1 • Indivisible instruction (non interruptible) • Memory, not cache • Locks memory bus (so other processors can’t access/change LOCK) • IA32 xchg and lock instructions

30. Mutex method 5: TSL instruction

31. Priority inversion problem • an unexpected consequence of busy wait • given H (a high priority job), and L (low priority job) • scheduling algorithm: whenever H is ready to run, L is preempted and H is run.

32. H runs… H blocks on I/O I/O completes H runs … H attempts to enter C.S. H busy waits forever! L is ready to run L runs … L enters C.S. … … L is preempted Priority inversion problem . . .

33. Using mutex (provided by OS) • Simpler than semaphore • Two states: locked or unlocked • Functions: • Declare mutex variable • Initialize mutex variable (just once) • lock ---> C.S. ---> unlock

34. #include <errno.h> #include <pthread.h> … pthread_mutex_tmutex; ///< declare global (i.e., not inside of any function) … //perform this one-time initialization (usually in main) int ret = pthread_mutex_init( &::mutex, NULL ); if (ret) { perror( "main: mutex init error" ); exit(-1); } … //lock in thread code ret = pthread_mutex_lock( &::mutex ); if (ret) { printf( "%d: mutex lock error \n", tp->whoAmI ); } //critical section here //unlock in thread code pthread_mutex_unlock( &::mutex );

35. #include <windows.h> … CRITICAL_SECTION g_cs; … //perform this one-time initialization (usually in main) InitializeCriticalSection( &g_cs ); … //lock in thread code EnterCriticalSection( &g_cs ); //critical section here //unlock in thread code LeaveCriticalSection( &g_cs );

36. Problem: • Modify filter program to also determine overall min and max of input data. • Can you do this with global variables? • Can you do this without global variables? • Which method requires mutex?

37. Semaphores

38. (Bounded) Producer-Consumer • A producer produces some item and stores it in a warehouse. • A consumer consumes an item by removing an item from the warehouse. • Notes: • The producer must pause production if the warehouse fills up (bounded). • If the warehouse is empty, the consumer must wait for something to be produced.

39. (Bounded) producer-consumerproblem Danger, Will Robinson (a shared variable)!

40. (Bounded) Producer-consumer problem • Buffer is initially empty. • Consumer checks count. It’s 0. • Scheduler interrupts consumer (puts consumer on ready queue). • Producer runs. • Insert data into buffer. • Count is 1 so producer wakes up consumer. • But consumer is not asleep just yet! (The scheduler interrupted it right before the call to sleep().) • Producer keeps inserting data into buffer until it’s full. Then producer goes to sleep! • Scheduler runs consumer. Consumer thinks count=0 so it goes to sleep! • Both sleep forever!

41. Semaphores • Invented by Dutch computer scientist EdsgerDijkstra. • Two basic operations: • Up • increments the value of the semaphore • historically denoted as V (also known as signal) • Down • decrements the value of the semaphore • P (also known as wait)

42. Semaphores Types: • POSIX • Shared only among threads. • Windows • Can be system-wide. • System V • Can be shared according to user-group-other (can be system-wide).

43. Binary semaphores = mutex • Create semaphore and initialize it to 1. • 1 = unlocked • 0 = locked • Then to use this as a mutex: • down • c.s. • up

44. Posix semaphores

45. POSIX Semaphores (shared among threads only) #include <semaphore.h> • intsem_init ( sem_t* sem, intpshared, unsigned int value ); • intsem_wait ( sem_t* sem ); • intsem_trywait ( sem_t* sem ); • intsem_post ( sem_t* sem ); • int sem_getvalue ( sem_t* sem, int* sval ); • intsem_destroy ( sem_t* sem );

46. POSIX Semaphores intsem_init ( sem_t* sem, intpshared, unsigned int value ); • initialize • pshared must be 0 on (some versions of) Linux • semaphore is not shared by processes • Value is initial value for semaphore.

47. POSIX Semaphores intsem_wait ( sem_t* sem ); • down (if possible/blocking) intsem_trywait ( sem_t* sem ); • nonblocking down • Blocking?

48. POSIX Semaphores intsem_post ( sem_t* sem ); • up (nonblocking) int sem_getvalue ( sem_t* sem, int* sval ); • get the current semaphore value intsem_destroy ( sem_t* sem ); • finish using the semaphore

49. Windows semaphores

50. Windows Semaphores HANDLE WINAPI CreateSemaphore ( __in_opt LPSECURITY_ATTRIBUTES lpSemaphoreAttributes, __in LONG lInitialCount, __in LONG lMaximumCount, __in_opt LPCTSTR lpName ); DWORD WINAPI WaitForSingleObject ( __in HANDLE hHandle, __in DWORD dwMilliseconds ); //decrements count by 1 BOOL WINAPI ReleaseSemaphore ( __in HANDLE hSemaphore, __in LONG lReleaseCount, __out_opt LPLONG lpPreviousCount ); //increments count by lReleaseCount BOOL WINAPI CloseHandle ( __in HANDLE hObject );