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
This entry was posted in Bounded Buffer Problem (no shared memory, Message Passing part2, Mutual Exclusion Based on Message Passing, Mutual Exclusion Based on Message Passing Code, Operating system.
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
This entry was posted in Computer Networks, Conclusion About Monitors and Semaphores, Design Issues, Message Passing, Monitors are high-level programming language concepts, Semaphores & Monitors, Semaphores are more lower-level.