1 / 25

More on Synchronization Interprocess Communication (IPC)

More on Synchronization Interprocess Communication (IPC). CS-502 Spring 2006. Interprocess Communication. Wide Variety of interprocess communication (IPC) mechanisms OS dependent Examples Pipes Sockets Shared memory

fleur-castaneda
Download Presentation

More on Synchronization Interprocess Communication (IPC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. More on SynchronizationInterprocess Communication (IPC) CS-502Spring 2006 CS502 Spring 2006

  2. 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 CS502 Spring 2006

  3. 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 CS502 Spring 2006

  4. 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 CS502 Spring 2006

  5. 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 } } CS502 Spring 2006

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

  7. 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 CS502 Spring 2006

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

  9. Monitors – Condition Variables CS502 Spring 2006

  10. 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 */ } } CS502 Spring 2006

  11. 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; • } CS502 Spring 2006

  12. 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 CS502 Spring 2006

  13. 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; • } CS502 Spring 2006

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

  15. 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 CS502 Spring 2006

  16. 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 CS502 Spring 2006

  17. 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 CS502 Spring 2006

  18. 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) CS502 Spring 2006

  19. 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); } } CS502 Spring 2006

  20. 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 CS502 Spring 2006

  21. 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 */ • } • } CS502 Spring 2006

  22. 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 CS502 Spring 2006

  23. 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 CS502 Spring 2006

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

  25. SummaryProcesses, 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”) CS502 Spring 2006

More Related