BSP workflow and superstep

[Diot Sebastien <s....@eurodata.de>]

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.: s.diot@eurodata.de     
-----------------------------------------------------
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
-----------------------------------------------------

Re: BSP workflow and superstep

[Suraj Menon <me...@gmail.com>]

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 <s....@eurodata.de> 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.: s.diot@eurodata.de
> -----------------------------------------------------
> 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
> -----------------------------------------------------
>
>
>