cy2003 computer systems lecture 06 interprocess communication monitors
TRANSCRIPT
CY2003Computer 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
Recall: Semaphores
© 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
© 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
© 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!
© 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!)
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
© 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).
© JMU, 2004 CY2003- Week 06 11
© 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;}
© 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
Message Passing
© 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?
© 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
© 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
Software Interrupts
UNIX Signals
© 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
© 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
© 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