cy2003 computer systems lecture 06 interprocess communication monitors

21
CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

Upload: ambrose-newman

Post on 01-Jan-2016

233 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

CY2003Computer Systems

Lecture 06

Interprocess Communication

Monitors

Page 2: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 2

Overview

• Recall: Semaphores theory

• Monitors

– Solving the producer-consumer problem

• Message passing

– solving synchronisation problems

• Software interrupts

– UNIX signals

Page 3: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

Recall: Semaphores

Page 4: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 4

Recall Semaphores

• A semaphore has two operations defined– down(s)

• if (s > 0)

• s = s -1

• else, sleep (blocks)

– up(s)• if there are processes waiting, then one is woken up

• if not, s = s +1

• Both these are guaranteed to be an atomic action– no other process can access the semaphore until the

operation has completed or blocked

Page 5: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 5

Semaphore Implementation

• The key to the successful functioning of the semaphore is the concept of atomicity

– as the semaphore is a closely controlled operating system primitive (e.g. system call) it can safely be implemented by disabling interrupts

• an application cannot abuse the interrupt handling

Page 6: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 6

Semaphore Difficulties• Recall the use of semaphores to solve the

producer-consumer problemwhile ( TRUE ) {

produce_item(item);down(empty);down(mutex);enter_item(item);up(mutex);up(full);

}

producerwhile ( TRUE ) {

down(full);down(mutex);remove_item(item);up(mutex);up(empty);consume_item(item);

}

consumer

• But! If the order of the down’s in the producer code are reversed, then the solution is ‘broken’

• if the buffer was full, the producer would perform a down on mutex and then block in the down on empty

• the consumer would then block in the down on mutex– both processes would stay blocked forever!

Page 7: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 7

Semaphore Limitations

• Semaphores are low-level constructs and so are difficult to program in practice

– higher level constructs have been proposed, but these require specially developed languages (i.e. not C!)

Page 8: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

Monitors

Page 9: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 9

Monitors

• To overcome the problem of semaphores, a higher level synchronisation primitive called monitor was introduced

• Monitor is a collection of procedures, variable, and data structure – Processes can call the monitor whenever they like– They cannot directly access the monitor’s internal

structure, from procedures outside the internal structure

• Only one process can be active in a monitor

Page 10: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 10

Monitors

• Monitors ensures mutual exclusion and there is no need to program it.

• However, there should be some way to ensure that processes block when they cannot proceed. – This is performed through condition variables and with

two operations which are wait and signal.• When monitor procedure discovers it cannot continue (e.g.

the producer discovers that the buffer is full), it does a wait on some condition variables (e.g. full).

Page 11: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 11

Page 12: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 12

Monitors

Condition full, empty; int count;

Monitor ProducerConsumer

void insert(int item){

if (count == N)wait(full);

inset_item(item);count = count + 1;if (count ==1)

signal(empty);}

int remove(){

if (count == 0)wait(empty);

item = remove_item();count = count - 1;if (count == N-1)

signal(full);return item;}

Page 13: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 13

Monitors

while ( TRUE ) {item = produce_item();ProducerConsumer.insert(item);

}

producer

while ( TRUE ) {item = ProducerConsumer.remove();consume_item(item);

}

consumer

• The wait and signal operations are similar to the sleep and weekup system calls. – however without suffering from their fatal deadlock

Page 14: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

Message Passing

Page 15: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 15

Message Passing

• Two message passing primitives are needed– send(destination, message)

• sends a message to a given destination• may block until the message is successfully sent

– receive(source, message)• receives a message from a given source• this will usually block until a message is received

• Although these are conceptually simple, there are many complex design issues to be considered– source and destination addresses may be on different

machines across a network: how are they named?– how are links established? what are their capacities?

Page 16: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 16

A Producer-Consumer Solution

• Assume that messages are a fixed size and that messages sent but not received are automatically stored by the operating system for future receipt

• there are 100 slots in our message buffer

int item;message m, empty;

while ( TRUE ){

produce_item(item);receive(consumer, empty);build_message(m, item);send(consumer, m);

}

producerint item;message m, empty;

for ( i= 0; i < 100; i++ )send(producer, empty);

while ( TRUE ) {receive(producer, m);extract_item(m, item);send(producer, empty);consume_item(item);

}

consumer

Page 17: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 17

Exception Conditions• A number of problems can occur with messages

– process termination• sender or receiver terminates before a message is processed• the OS needs to catch these conditions to prevent deadlock

– lost messages• a message may be lost in the communication network• one solution is to require acknowledgement messages

– a message is resent if the acknowledgement is not received– but what happens if an acknowledgement is lost !?

– scrambled messages• a message may be corrupted in the communication network• include checksum information to detect this & resend

– authentication• an imposter may intercept the delivery of a message• a solution may be some encryption with authentication keys

Page 18: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

Software Interrupts

UNIX Signals

Page 19: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 19

UNIX Signals

• A UNIX signal is similar to a software interrupt– a process may send a signal to another process– when a signal arrives, the receiving process stops

what it is doing and immediately services the signal

• A signal is sent by using the kill system callkill(process_id, signal_number);

• The action taken when a signal is received by a process is specified by the signal system call– it can (usually) be ignored– it can terminate the process– it can be ‘caught’ by a special signal handling function

Page 20: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 20

Signal Examples

SIGKILL sent to a process to immediately kill it• this signal cannot be caught or ignored• typically used by the system to stop processes at shutdown or by

root to kill runaway processes via the ‘kill’ command

SIGFPE floating point error

SIGINT/QUIT two levels of keyboard interrupt• SIGINT is ‘gentler’: interpreted as a request to stop • SIGQUIT is ‘harder’: an instruction to stop

Page 21: CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004 CY2003- Week 06 21

Summary

• Recall: Semaphores theory

• Monitors

– Solving the producer-consumer problem

• Message passing

– Solving the producer-consumer problem

• Software interrupts

– UNIX signals