Synchronization Methods in Message Passing Model Message Passing

  • Slides: 13
Download presentation
Synchronization Methods in Message Passing Model

Synchronization Methods in Message Passing Model

Message Passing Model v Channel Specification Ø Specify how to communicate v Synchronization Mechanisms

Message Passing Model v Channel Specification Ø Specify how to communicate v Synchronization Mechanisms Ø The synchronization mechanism between sender and receiver Ø Block/nonblock send, block/nonblock receive Ø Guarded communication

Channel Specification v Direct naming Ø Simple but less powerful Ø Not suitable for

Channel Specification v Direct naming Ø Simple but less powerful Ø Not suitable for specification of server-client systems v Port naming Ø Server use a single port to receive client request Ø Simple, suitable for single server, multiple client systems v Global naming (mailbox) Ø Suitable for multiple server, multiple client systems Ø Hard to implement for multiple processor systems Ø When a message is received or removed, all servers should be notified

Synchronization v Blocked send, blocked receive (BSBR) Ø Easy to implement but less powerful

Synchronization v Blocked send, blocked receive (BSBR) Ø Easy to implement but less powerful Ø Example: Ada Rendezvous v Nonblocked send, blocked receive (NSBR) Ø Most message passing systems use this model Ø need unbounded message queue to assure correctness v Nonblocked send, nonblocked receive (NSNR) Ø More powerful than NSBR and BSBR Ø But difficult to reason the correctness of the system § The state of the system can be very different at the time the message is received

Producers-Consumer Problem v Consider multiple producers and multiple consumers Ø Any producer’s output can

Producers-Consumer Problem v Consider multiple producers and multiple consumers Ø Any producer’s output can be processed by any consumer v Use port naming Ø Each process has a port Ø Won’t work since each producer needs to decide which consumer the produced item should be sent to § Not conform to the spec v Use a buffer manager Ø Assume only port naming is available Ø The manager manage a shared buffer Ø Similar to mailbox, but user implements shared box

Producers-Consumer Problem v Solution based on buffer manager and port naming Ø How to

Producers-Consumer Problem v Solution based on buffer manager and port naming Ø How to synchronize the producers and consumers with the bounded buffer § Buffer full Stop receiving messages from producers § Buffer empty Stop receiving messages from consumers § Need blocked send to achieve the control Ø Manager needs two ports, one for consumers, one for producers § Otherwise, cannot block only consumers or only producers § Still have problem: How to read from two ports Ø Solution 1: Use blocked receive and two threads § Manager cannot do blocked receive on both ports Ø Solution 2: Use nonblocked receive § Poll two ports using BSNR

Producer-Consumer Problem v Manager process (Pmamnager) Ø reqport: manager receives requests from consumers Ø

Producer-Consumer Problem v Manager process (Pmamnager) Ø reqport: manager receives requests from consumers Ø dataport: manager receives data items from producers Ø BSNR § Receive returns immediately, it returns true if a message is ready in the port, otherwise, false § Send only returns after the message is received Ø count: # data items in Pmamnager’s buffer

Producer-Consumer Problem Producer Process: repeat produce item; send (dataport, item); until false; Consumer Process:

Producer-Consumer Problem Producer Process: repeat produce item; send (dataport, item); until false; Consumer Process: repeat send (reqport, localport); while not receive (localport, item) do nothing; consume item; until false;

Producer-Consumer Problem Manager Process: repeat forever if count = 0 then { while not

Producer-Consumer Problem Manager Process: repeat forever if count = 0 then { while not receive (dataport, item) do nothing; put item in the queue; count : = count + 1; } else if count = N then { while notreceive (reqport, port) do nothing; take item from queue; count : = count - 1; send (port, item); } else { if receive (dataport, item) then { put item in the queue; count : = count + 1; } if receive (reqport, port) then { take item from queue; count : = count - 1; send (port, item); } }

Guarded Command v Guarded command Ø Guarded statement: G S § When the guard

Guarded Command v Guarded command Ø Guarded statement: G S § When the guard G is true, execute statement S Ø Guarded command in CSP if G 1 S 1 || G 2 S 2 ||. . . || Gn Sn fi § When Gi is true, execute Si § If more than one guard is true, then choose one of them arbitrarily and execute the corresponding statement § If none of the guards are true, then terminate the statement without doing anything

Guarded Communication v Guarded communication: Ø Statements in a guarded command contain message passing

Guarded Communication v Guarded communication: Ø Statements in a guarded command contain message passing operations Ø Message passing is based on BSBR Ø A guarded communication statement is ready when § The guard is true § For receive statement: The message to be received is ready § For send statement: The receiver of the message is ready Ø If none of the guards are true, then terminate the statement Ø If some guards are true and no message is ready then blocked

Producer-Consumer Problem Manager Process: repeat select when count < N { receive (dataport, item);

Producer-Consumer Problem Manager Process: repeat select when count < N { receive (dataport, item); -- from producer put item in the queue; count : = count + 1; } when count > 0 { receive (reqport, port); -- from consumer take item from queue; send (port, item); count : = count - 1; } until false;

Guarded Communication v Guarded communication in Ada: select when G 1 => accept P

Guarded Communication v Guarded communication in Ada: select when G 1 => accept P 1 do. . end; when G 2 => accept P 2 do. . end; …. . else. . ; end select v Now guarded communication is adopted in socket Ø Gradually being adopted for server implementation Ø Better performance than thread based implementation