Synchronization and IPC 1 CS502 Spring 2006 More on Synchronization Interprocess Communication (IPC) CS-502 Spring 2006

Synchronization and IPC 2 CS502 Spring 2006 Interprocess Communication Wide Variety of interprocess communication (IPC) mechanisms –OS dependent –Examples Pipes Sockets Shared memory Depends on whether the communicating processes share all or part of an address space

Synchronization and IPC 3 CS502 Spring 2006 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

Synchronization and IPC 4 CS502 Spring 2006 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. 1974

Synchronization and IPC 5 CS502 Spring 2006 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 }

Synchronization and IPC 6 CS502 Spring 2006 Monitors shared data operations (procedures) at most one process in monitor at a time

Synchronization and IPC 7 CS502 Spring 2006 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

Synchronization and IPC 8 CS502 Spring 2006 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.

Synchronization and IPC 9 CS502 Spring 2006 Monitors – Condition Variables

Synchronization and IPC 10 CS502 Spring 2006 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 (1) { /* produce item i */ ProducerConsumer.insert(i); } void consumer() { item i; while (1) { i = ProducerConsumer.remove(); /* consume item i */ }

Synchronization and IPC 11 CS502 Spring 2006 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; }

Synchronization and IPC 12 CS502 Spring 2006 Monitors Hoare monitors: signal(c) means –run waiter immediately –signaler blocks immediately condition guaranteed to hold when waiter runs Mesa monitors: signal(c) means –waiter is made ready, but the signaler may continue waiter runs 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

Synchronization and IPC 13 CS502 Spring 2006 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; }

Synchronization and IPC 14 CS502 Spring 2006 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 Redell, D. D. et al. “Pilot: An Operating System for a Personal Computer,” Communications of ACM, vol. 23, pp , Feb

Synchronization and IPC 15 CS502 Spring 2006 Interprocess Communication Common IPC mechanisms –shared memory – read/write to shared region shmget(), shmctl() in Unix Memory mapped files in WinNT/2000 –semaphores - signal 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

Synchronization and IPC 16 CS502 Spring 2006 IPC – Software Interrupts Similar to hardware interrupt. Processes interrupt each other 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

Synchronization and IPC 17 CS502 Spring 2006 IPC – Software Interrupts 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

Synchronization and IPC 18 CS502 Spring 2006 IPC - Pipes Pipes are a uni-directional stream communication method between 2 processes –Unix/Linux 2 file descriptors Byte stream –Win/NT 1 handle Byte stream and structured (messages)

Synchronization and IPC 19 CS502 Spring 2006 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); }

Synchronization and IPC 20 CS502 Spring 2006 IPC – Message Passing Communicate information from one process to another via primitives: send(dest, &message) receive(source, &message) Receiver can specify ANY Receiver can block (or not) Applicable to multiprocessor systems

Synchronization and IPC 21 CS502 Spring 2006 IPC – Message Passing void Producer() { while (TRUE) { /* produce item */ build_message(&m, item); send(consumer, &m); receive(consumer, &m); /* wait for ack */ } void Consumer { while(TRUE) { receive(producer, &m); extract_item(&m, &item); send(producer, &m); /* ack */ /* consume item */ }

Synchronization and IPC 22 CS502 Spring 2006 IPC – Message Passing –send ( ) 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 () Sync. –Returns if there is a message –Blocks if not Async. –Returns if there is a message –Returns if no message

Synchronization and IPC 23 CS502 Spring 2006 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 –Many to many communication

Synchronization and IPC 24 CS502 Spring 2006 IPC – Message Passing Scrambled messages (checksum) Lost messages (acknowledgements) Lost acknowledgements (sequence no.) Process unreachable (down, terminates) Naming Authentication Performance (from copying, message building

Synchronization and IPC 25 CS502 Spring 2006 Summary Processes, Threads, Synchronization, IPC Process – fundamental unit of concurrency; exists in some form in all modern OS’s Threads – a special adaptation of process for efficiency in Unix, Windows, etc. Synchronization – many methods to keep processes from tripping over each other IPC – many methods for communication among processes Responsible for all of Chapter 2 of Tannenbaum, except §2.4 (“Classical IPC Problems”)