Month: February 2015
Inter-Process Communication
Mutual Exclusion Based on Message Passing
Mutual Exclusion Based on Message Passing Code
P1:
send(Resource Contro, “Give me resource”);
receive(Resource Controller, Message);
// block while waiting for a reply from RC
{
…Critical Section…
}
send(Resource Controller, “Done with resource”);
Bounded Buffer Problem (no shared memory)
void consumer(void)
int item;
message m;
// initialization loop
for (i=0; i<N; i++) send(producer, &m);// N empty slots
while (TRUE) {
receive(producer, &m); // receive item
item=extract_item(&m);
send(producer, &m); // send empty slot
consume_item(item);
}
void producer(void)
int item;
message m;
while (TRUE) {
item Produce_Item();
receive(consumer, &m); // empty slot
build_message(&m, item);
send(consumer, &m); // send item
}
Posted By-: Vissicomp Technology Pvt. Ltd.
Website -: http://www.vissicomp.com
Inter-Process Communication
Semaphores & Monitors
• Monitors are high-level programming language concepts
– Make mutual exclusion of critical section “automatic” and therefore less error-prone
– Require compiler support
– Not widely available in modern languages (e.g., avail. In Modula 3)
– Available as an “approximation”in Java
• Semaphores are more lower-level
– Require OS support
– Applications can be layered on top of them, i.e., no compiler support required
• Both concepts require some kind of shared memory
• How about synchronization problems in a distributed system (no shared memory)?
Conclusion About Monitors and Semaphores
• Monitors are high-level, but not widely supported; therefore not too useful in practice
• Semaphores are rather low-level
• None of the mechanisms discussed so far allow for information exchange between
distributed processes So we need something else!
Message Passing
•An inter-process communication mechanism
• Based on two primitives
–send (destination, &message)
• Sends a message to a destination
–receive (source, &message)
• Receives a message from a source (any source)
• System calls, not language constructs
• Blocking versions and non-blocking versions are available.
Message Passing
• Naming of sender / receiver
• Number of interacting entities
• Reliability of link
• Capacity of link
Design Issues:
Various design concerns not applicable in semaphore & monitor discussion:
• Networked system, i.e., messages may be lost (network is unreliable)
• Sender/receiver agree to use acknowledgements and retransmission timers
• Message received, but acknowledgement lost
– Receiver will get the same message twice
– Use consecutive sequence numbers
–Computer Networks
• Naming of processes for unambiguous send/receive
• Authentication, how can client know it is communicating with proper server
• Tune for performance, if sender & receiver are on the same machine (semaphore is usually cheaper)
Posted By-: Vissicomp Technology Pvt. Ltd.
Website -: http://www.vissicomp.com
