CY2003 Computer Systems Lecture 06 Interprocess Communication Monitors

© JMU, 2004CY2003- Week 062 Overview Recall: Semaphores theory Monitors –Solving the producer-consumer problem Message passing –solving synchronisation problems Software interrupts –UNIX signals

Recall: Semaphores

© JMU, 2004CY2003- Week 064 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, 2004CY2003- Week 065 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, 2004CY2003- Week 066 Semaphore Difficulties Recall the use of semaphores to solve the producer-consumer problem while ( TRUE ) { produce_item(item); down(empty); down(mutex); enter_item(item); up(mutex); up(full); } producer while ( 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, 2004CY2003- Week 067 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, 2004CY2003- Week 069 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, 2004CY2003- Week 0610 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, 2004CY2003- Week 0611

© JMU, 2004CY2003- Week 0612 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, 2004CY2003- Week 0613 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, 2004CY2003- Week 0615 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, 2004CY2003- Week 0616 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); } producer int 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, 2004CY2003- Week 0617 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, 2004CY2003- Week 0619 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 call kill(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, 2004CY2003- Week 0620 Signal Examples SIGKILLsent 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 SIGFPEfloating point error SIGINT/QUITtwo levels of keyboard interrupt SIGINT is ‘gentler’: interpreted as a request to stop SIGQUIT is ‘harder’: an instruction to stop

© JMU, 2004CY2003- Week 0621 Summary Recall: Semaphores theory Monitors –Solving the producer-consumer problem Message passing –Solving the producer-consumer problem Software interrupts –UNIX signals