CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 1 More on Synchronization Interprocess Communication (IPC) CS-3013 & CS-502 Summer 2006

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 2 Interprocess Communication Wide Variety of interprocess communication (IPC) mechanisms – e.g., Pipes & streams Sockets & Messages Remote Procedure Call Shared memory –OS dependent Depends on whether the communicating processes share all or part of an address space

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 3 Interprocess Communication Common IPC mechanisms –shared memory – read/write to shared region E.g., shmget(), shmctl() in Unix Memory mapped files in WinNT/2000 Need critical section management –semaphores – post_s() notifies waiting process Shared memory or not –software interrupts - process notified asynchronously signal () –pipes - unidirectional stream communication –message passing - processes send and receive messages Across address spaces

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 4 IPC – Software Interrupts Similar to hardware interrupt. –Processes interrupt each other –Non-process activities interrupt processes Asynchronous! Stops execution then restarts –Keyboard driven – e.g. cntl-C –An alarm scheduled by the process expires Unix: SIGALRM from alarm() or settimer() –resource limit exceeded (disk quota, CPU time...) –programming errors: invalid data, divide by zero

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 5 Software Interrupts (continued) SendInterrupt(pid, num) –Send signal type num to process pid, –kill() in Unix –(NT doesn’t allow signals to processes) HandleInterrupt(num, handler) –type num, use function handler –signal() in Unix –Use exception handler in WinNT/2000 Typical handlers: –ignore –terminate (maybe w/core dump) –user-defined

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 6 Software Interrupts (continued) Will need to use software interrupts for Programming Project #3 (Web Server) –For cleanly exiting the server

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 7 IPC – Pipes A pipe is a unidirectional stream connection between 2 processes –Unix/Linux 2 file descriptors Byte stream –Win/NT 1 handle Byte stream and structured (messages)

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 8 IPC – Pipes #include #include <unistd.h #include #define BUFFSIZE 1024 char data[ ] = “whatever” int pipefd[2]; /* file descriptors for pipe ends */ /* NO ERROR CHECKING, ILLUSTRATION ONLY!!!!! */ main() { char sbBuf[BUFFSIZE]; pipe(pipefd); if (fork() > 0 ) { /* parent, read from pipe */ close(pipefd[1]); /* close write end */ read(pipefd[0], sbBuf, BUFFSIZE); /* do something with the data */ } else { /* child, write data to pipe */ close(pipefd[0]); /* close read end */ write(pipefd[1], data, sizeof(DATA)); close(pipefd[1]); exit(0); }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 9 IPC – Message Passing Communicate information from one process to another via primitives: send(dest, &message) receive(source, &message) Receiver can specify ANY Receiver can choose to block or not Applicable to multiprocessor and distributed systems

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 10 IPC – Message Passing void Producer() { while (TRUE) { /* produce item */ build_message(&m, item); send(consumer, &m); /* send message */ receive(consumer, &m); /* wait for ack */ } void Consumer { while(TRUE) { receive(producer, &m); /* receive message */ extract_item(&m, &item); send(producer, &m); /* send ack */ /* consume item */ }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 11 IPC – Message Passing –send ( ) operation Synchronous –Returns after data is sent –Blocks if buffer is full Asynchronous –Returns as soon as I/O started –Done? »Explicit check »Signal –Blocks if buffer is full –receive () operation Sync. –Returns if there is a message –Blocks if not Async. –Returns if there is a message –Returns indication if no message

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 12 IPC – Message Passing Indirect Communication – mailboxes –Messages are sent to a named area – mailbox –Processes read messages from the mailbox –Mailbox must be created and managed –Sender blocks if mailbox is full –Enables many-to-many communication

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 13 Message Passing issues Scrambled messages (checksum) Lost messages (acknowledgements) Lost acknowledgements (sequence no.) Process unreachable (down, terminates) Naming Authentication Performance (copying, message building)

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 14 Beyond Semaphores Semaphores can help solve many traditional synchronization problems, BUT: –Have no direct relationship to the data being controlled –Difficult to use correctly; easily misused Global variables Proper usage requires superhuman attention to detail Another approach – use programming language support

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 15 Monitors Programming language construct that supports controlled access to shared data –Compiler adds synchronization automatically –Enforced at runtime Encapsulates –Shared data structures –Procedures/functions that operate on the data –Synchronization between processes calling those procedures Only one process active inside a monitor at any instant –All procedures are part of critical section Hoare, C.A.R., “Monitors: An Operating System Structuring Concept,” Communications of ACM, vol. 17, pp , Oct (.pdf).pdf

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 16 Monitors High-level synchronization allowing safe sharing of an abstract data type among concurrent processes. monitor monitor-name { shared variable declarations procedure body P1 (…) {... } procedure body P2 (…) {... } procedure body Pn (…) {... } { initialization code }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 17 Monitors shared data operations (procedures) at most one process in monitor at a time

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 18 Monitors Mutual exclusion –only one process can be executing inside at any time –if a second process tries to enter a monitor procedure, it blocks until the first has left the monitor Once inside a monitor, process may discover it is not able to continue condition variables provided within monitor processes can wait or signal others to continue condition variable can only be accessed from inside monitor wait’ing process relinquishes monitor temporarily

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 19 Monitors To allow a process to wait within the monitor, a condition variable must be declared, as condition x, y; Condition variable can only be used with the operations wait and signal. –The operation wait(x); means that the process invoking this operation is suspended until another process invokes signal(x); –The signal operation resumes exactly one suspended process. If no process is suspended, then the signal operation has no effect.

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 20 wait and signal (continued) When process invokes wait, it reliquishes the monitor lock to allow other processes in. When process invokes signal, the resumed process must reacquire monitor lock before it can proceed (inside the monitor)

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 21 Monitors – Condition Variables

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 22 Monitors monitor ProducerConsumer { condition full, empty; integer count = 0; /* function prototypes */ void insert(item i); item remove(); } void producer(); void consumer(); void producer() { item i; while (TRUE) { /* produce item i */ ProducerConsumer.insert(i); } void consumer() { item i; while (TRUE) { i = ProducerConsumer.remove(); /* consume item i */ }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 23 Monitors void insert (item i) { if (count == N) wait(full); /* add item i */ count = count + 1; if (count == 1) then signal(empty); } item remove () { if (count == 0) wait(empty); /* remove item into i */ count = count - 1; if (count == N-1) signal(full); return i; }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 24 Monitors – variations Hoare monitors: signal(c) means –run waiter immediately (and acquires monitor lock) –signaler blocks immediately (and releases lock) condition guaranteed to hold when waiter runs Mesa/Pilot monitors: signal(c) means –waiter is made ready, but signaler continues waiter competes for monitor lock when signaler leaves monitor (or waits) condition is not necessarily true when waiter runs again –being woken up is only a hint that something has changed must recheck conditional case

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 25 Monitors (Mesa) void insert (item i) { while (count == N) wait(full); /* add item i */ count = count + 1; if (count == 1) then signal(empty); } item remove () { while (count == 0) wait(empty); /* remove item into i */ count = count - 1; if (count == N-1) signal(full); return i; }

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 26 Synchronization Semaphores –Easy to add to any language –Much harder to use correctly Monitors –Easier to use and to get it right –Must have language support See Lampson, B.W., and Redell, D. D., “Experience with Processes and Monitors in Mesa,” Communications of ACM, vol. 23, pp , Feb (.pdf).pdf Redell, D. D. et al. “Pilot: An Operating System for a Personal Computer,” Communications of ACM, vol. 23, pp , Feb (.pdf).pdf

CS 3013 & CS 502 Summer 2006 IPC, Synchronization, and Monitors 27 Break (next topic)