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

1

More on SynchronizationInterprocess

Communication (IPC)CS-3013 & CS-502

Summer 2006

CS 3013 & CS 502 Summer 2006


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


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


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


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


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


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


8

IPC – Pipes#include <iostream.h>#include <unistd.h#include <stdlib.h>#define BUFFSIZE 1024char 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


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


10

IPC – Message Passingvoid 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


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


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


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


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


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)

CS 3013 & CS 502 Summer 2006


16

Monitors• High-level synchronization allowing safe

sharing of an abstract data type among concurrent processes.

monitor monitor-name{

shared variable declarationsprocedure body P1 (…) {

. . .}procedure body P2 (…) {

. . .} procedure body Pn (…) {

. . .} {

initialization code}

}

CS 3013 & CS 502 Summer 2006


17

Monitors

shared data

operations (procedures)at most one process in monitor

at a time

CS 3013 & CS 502 Summer 2006


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


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


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


21

Monitors – Condition Variables

CS 3013 & CS 502 Summer 2006


22

Monitorsmonitor 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


23

Monitorsvoid 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


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


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


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)

CS 3013 & CS 502 Summer 2006


27

Break

(next topic)

Documents

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