Synchronization and IPC 1 CS502 Spring 2006 More on Synchronization Interprocess Communication (IPC)...

Synchronization and IPC 1

More on SynchronizationInterprocess Communication (IPC)

CS-502Spring 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


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


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


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}

}


Monitors

shared data

operations (procedures)at most one process in monitor

at a time


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


Monitors• To allow a process to wait within the monitor, a

condition variable must be declared, ascondition 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.


Monitors – Condition Variables


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 (1) {

/* produce item i */ ProducerConsumer.insert(i);

}

}

void consumer() {

item i;

while (1) {

i = ProducerConsumer.remove();

/* consume item i */

}

}


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;

}


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


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

• 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.


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


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


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


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)


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);

}}


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


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

}

}


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


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


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

building


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”)

Date post:	20-Dec-2015
Category:	Documents
View:	230 times
Download:	1 times

Synchronization and IPC 1 CS502 Spring 2006 More on Synchronization Interprocess Communication (IPC)...

Documents