There is a bug with this program: it will enter a deadlock. When each thread calls send(), the call will not return until the message has been received (by a call to recv() in another thread). But since every thread is calling send() before calling recv(), all of them will be waiting for another thread to call recv(), which will never happen, causing the deadlock.

This can be fixed by having odd-numbered threads recv() first and send() later, and even-numbered threads doing the opposite, as implemented on slide 13.

Assigning send and receive commands on odd number threads as a fix for this deadlock will create a sequential program even though it is correct.

@mario Actually, it won't create a sequential program. What haoala meant was that all the odd-numbered threads will wait to receive information while all the even-numbered threads send the data in parallel. Then after all the threads are synced up, the odd numbered threads will have their turn sending their data while the even numbered threads wait to receive the data. All the threads will be either sending or receiving in parallel. Then they can execute their computations in parallel. We are simply statically assigning who will be receiving and who will be sending and when. It doesn't become completely sequential.

A purely sequential program is created if you have odd numbered rows send twice, and even threads receive twice - because the last row has to send for the row before it to receive, and then only can the next row receive, and so on and so forth, creating a cascade effect.