IPC, Synchronization, and Monitors

1. More on SynchronizationInterprocess Communication (IPC) CS-3013 & CS-502Summer 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 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 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 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 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 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) IPC, Synchronization, and Monitors

8. IPC – Pipes #include <iostream.h> #include <unistd.h #include <stdlib.h> #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); } } 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 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 */ • } • } 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 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 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) 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 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. 549-557, Oct. 1974 (.pdf) 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 bodyP1(…) { . . . } procedurebodyP2 (…) { . . . } procedure bodyPn(…) { . . . } { initialization code } } IPC, Synchronization, and Monitors

17. Monitors shared data at most one process in monitor at a time operations (procedures) 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 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. 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) IPC, Synchronization, and Monitors

21. Monitors – Condition Variables 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 */ } } 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; } 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 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; } 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. 105-117, Feb. 1980. (.pdf) • Redell, D. D. et al. “Pilot: An Operating System for a Personal Computer,” Communications of ACM, vol. 23, pp. 81-91, Feb. 1980. (.pdf) IPC, Synchronization, and Monitors

27. Break (next topic) IPC, Synchronization, and Monitors