Jeff, I agree that the code I supplied has no interesting parallelism. That code was simply an attempt to diagnose or replicated an error I was getting with a more complicated code which also had shared memory structures pointing to other shared memory structures. The linked list was just a quick example of a similar structure to test what the issue could be. It ended up having very similar error behavior as the original program so I thought I would share it instead of a more complicated project. For the project I was working on I wanted to create large shared memory structures that would be read-only once the initial set-up was done. Some of these shared memory structures were to have shared memory structures allocated within them, which appeared to generate the errors I was encountering. If you are interested in the original code that produced these errors it is posted at: https://github.com/bcornille/mpi-shared-ne506/tree/develop/src (mostly in geoms.c) There are likely ways that I could change the structure of the code to work around this problem, but I was hoping to try to understand what was causing the very strange errors that I produced. I encountered errors when I tried to make assignments to shared memory regions that were pointed to from other shared memory regions. I am hoping that the error in the code I provided is the mirror image of the error in my original code. Thanks and best, Brian Cornille On Sat, May 2 at 5:46 PM, Jeff Hammond <[email protected]> wrote:
I do not understand what this program is supposed to do. MPI_Win_allocate_shared is collective, as is MPI_Win_fence, so I don't see how any interesting parallelism emerges from this type of implementation of a linked-list.
Are you just using the linked-list to manage a collection of shared memory windows (GMR does this in http://git.mpich.org/armci-mpi.git/blob/HEAD:/src/gmr.c, for example)?
If you want to do a distributed linked-list using RMA, I recall there is a linked-list example in the MPI-3 spec or perhaps somewhere else (somebody on this list will remember, or I can look it up). And this example probably uses MPI_Win_create_dynamic and MPI_Win_attach, which means no interprocess load-store.
Jeff
On Sat, May 2, 2015 at 4:06 PM, Junchao Zhang <[email protected]> wrote:
I can reproduce the segfault with the latest mpich. In Clean_List(), I think there is a data race, since all shmem members update the head node head->next_win = temp_win; head->next = temp_next; I tried to simplify Clean_List() further as follows,
void Clean_List() { Node *cur_node = head; MPI_Win cur_win = head_win; Node *next_node; MPI_Win next_win;
while (cur_node) { next_node = cur_node->next; next_win = cur_node->next_win; MPI_Win_free(&cur_win); cur_node = next_node; cur_win = next_win; }
head = tail = NULL; }
But I still met segfault. With gdb, the segfault disappears. If I comment out the call to Clean_List in main(), the error also disappear. I Cc'ed our local RMA expert Xin to see if she has new findings.
--Junchao Zhang
On Sat, May 2, 2015 at 10:26 AM, Brian Cornille <[email protected]> wrote:
Hello,
In working on a project that is attempting to use MPI shared memory (from MPI_Win_allocate_shared) I began getting inconsistent segfaults in portions of the code that appeared to have no memory errors when investigated with gdb. I believe I have somewhat reproduced this error in a small code (attached) that creates a linked list of MPI shared memory allocated elements.
The attached program segfaults for me when run with more than one process. However, will not segfault if run in gdb (e.g. mpirun -n 2 xterm -e gdb ./mpi_shmem_ll). I have done what I can to eliminate any apparent race conditions. Any help in this matter would be much appreciated.
Thanks and best,
Brian Cornille
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss