Thank you providing the perspective. A peer does not have to wait for the messages per se. If any other peers had sent messages to it in the previous superstep, those messages are provided for processing when the current superstep execution begins after barrier synchronization. So if no message is received, the implementation has to handle it in processing and enter the barrier synchronization(sync).
Unlike parallel programming model like PRAM or its other variants with shared memory, BSP provides the following guarantees: (picked from https://issues.apache.org/jira/secure/attachment/12528218/ApacheHamaBSPProgrammingmodel.pdf ) When a peer enters the barrier synchronization mode, it is implied that : ● Peer has completely executed the superstep. ● All the messages for each of the others peers are (most of the times reliably) sent out. ● Peer is waiting for all other peers to enter the barrier. When a peer leaves a barrier, it is implied that : ● The peer is about to start working on the next superstep. ● There are no other peers in the system working on the previous superstep. ● A peer gets all the messages, sent to it by other peers in the previous superstep, as input for the new superstep execution. This avoids the need for programmer to handle deadlocks or other resource contention issues. By Actor model, are referring to jobs with tasks defined as DAG because that is something we are looking at in future. Otherwise you can have dormant peers that would respond if any other peer sent message to it in the previous superstep. I am not sure if I answered your question here. -Suraj On Sat, Sep 22, 2012 at 9:52 AM, Diot Sebastien <[email protected]> wrote: > Hi. > > The BSP tutorial page says that BSP workflow is: > > Local computation > Process communication > Barrier synchronization > > While this makes sense for the bootstraping jobs, I think that describing > the workflow like this makes more sense for an already bootstrapped job: > > Sync > Receive messages > Process messages > Send messages > > in the sense that once all messages have been processed by a job, all it > can do is wait for new messages by syncing. So it seems to me that the > start of the cycle should not be described as local processing, but rather > as waiting for instructions. This is similar to the Actor model, where the > actors are strictly reactive, and become dormant when they do not get > messages. Or, for a real world analogy, I get to work, read my emails and > other work sources, do the work, send replies, and then go home and wait > for the next day to get more work... > > Am I missing something? > > MfG / Regards, > Sebastien Diot > > Grossblittersdorferstrasse 257-259 > 66119 Saarbruecken > Germany > Tel.: +49 (681) 8808-0 > Fax.: +49 (681) 8808-300 > E-Mail.: [email protected] > ----------------------------------------------------- > EURO DATA GmbH & Co. KG > Datenverarbeitungsdienst > HR A 6448 Amtsgericht Saarbrücken > Komplementär: A. Reiß & Sohn GmbH > HR B 4965 Amtsgericht Saarbrücken > Geschäftsführer: Dipl.-Kfm. Karl-Heinz Siebenpfeiffer > ----------------------------------------------------- > > >
