1 December. Just to clarify something that a few students have been confused about: you may assume that each process calls dsm_sync the same number of times. If the user doesn't do this, nothing is gauranteed to work.
19 November. If you want to assume/require that dsm_dump() is a global blocking call, that's probably a good idea. If you can assume that everyone calls it, it will probably simplify your life.
11 November. It's fine if you want to use a few carefully selected global variables in your implementation. If you are writing in C and you can't stand globals, you could add another parameter to every function, analogous to the MPI communicator. That argument could be a pointer to a struct that holds any state that more than one DSM function needs to know. In general, feel free to modify the API if you think it helps.
10 November. You may assume that no other MPI communication takes place in the user's program. This means that you are free to use MPI_COMM_WORLD for all the communication. (Note: this is simpler than what we said in class today.)
10 November. It's fine if one or more of your functions does some "busy waiting". For example, my design for dsm_get() has a loop that repeatadly looks for and handles any requests that have come in, until the particular piece of data that this call is looking for arrives. You may have other approaches of course.
10 November. The dsm_sync() function takes some careful thought. Be sure that your implementation doesn't allow one process to dive into a global synchronization call (e.g., and MPI_Barrier or MPI_Allreduce) until it knows that no one else needs something from that process. My solution isn't very efficient. But it works.
9 November. You may assume that all processes call dsm_init() with the same value for length.