Steve
>
> In a BARRIER-based model, like the main draft:
>
> Process 1 Process 2 Process 3
>
> read
> BARRIER BARRIER BARRIER
> PUT to 1 PUT to 1
> compute compute
> PUT to 1 PUT to 1
> BARRIER BARRIER BARRIER
> WINDOW_IN
> read
> BARRIER BARRIER BARRIER
> PUT to 1 PUT to 1
> compute compute
> PUT to 1 PUT to 1
> BARRIER BARRIER BARRIER
> WINDOW_IN
> etc.
>
> Note that the first BARRIER is to ensure that nobody starts writing to
> process 1 while it is still reading. What happens to process 2 and 3
> at the beginning? They stop and wait for the barrier. When 1 is done
> reading, and the barrier clears, the they do their thing, then they
> need to sync again while 1 reads again.
>
> Same example in the PUT/ACCEPT model.
>
> read
> ACCEPTC
> PUTC to 1 PUTC to 1
> compute compute
> PUTC to 1 PUTC to 1
> ACCEPTC ACCEPTC
> read
> ACCEPTC
> PUTC to 1 PUTC to 1
> compute compute
> PUTC to 1 PUTC to 1
> ACCEPTC ACCEPTC
>
> Note that 2 and 3 immediately hit the PUTC. If the read on 1 has finished, and
> 1 is executing its ACCEPTC, then 2 and 3 can immediately move bits, as above.
> But, unlike above, if 1 isn't done with the read yet, 2 and 3 can just store
> away the PUTCs and go on to do the compute. When they get to the next PUTC,
> they can check again whether 1 has reached its ACCEPTC, and the same goes
> again-- if it has not finished, they store away the PUTC, otherwise they move
> bits (along with those in the stored PUTC if necessary). Finally, 2 and 3 hit
> the ACCEPTC, and now they *will* wait until 1 finishes the read and
> executes the ACCEPTC.
>
> So, yes, in this example, I claim that the PUT/ACCEPT model is "more efficient"
> that the main draft.