Ryan, What you witness in your execution is that your execution over 2 processes drifted by 49 iterations. Because your example avoid any synchronization call, your processes are not synchronized and therefore any output (in increment of quatum) is correct. As Gilles suggested, enabling the shmem_barrier before the printf will guarantee that all processes are at the same spot, thus all remote (and local) AMO are completed, and therefore the result will be the expected value.
George. On Wed, Apr 20, 2016 at 1:33 PM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > Ryan, > > what if you uncomment the barrier before printf ? > > I can see a scenario in which printf is invoked on rank 0 before all > shmem_long_add have started/completed on rank 1 > > Cheers, > > Gilles > > On Wednesday, April 20, 2016, RYAN RAY <ryan....@rediffmail.com> wrote: > >> While executing the code in the file *exp4.c* (Attached) we faced >> undesired result. This code allows all PEs to *add a 'quantum' value to >> a variable on a particular host*. But in some cases few of these *'quantum' >> values are lost*. I have attached the file and a screenshot of the >> output. In the screenshot the last execution is missing 49 quantums. I will >> be obliged if you could explain to me why this is happenning. >> >> Regards, >> Ryan Ray >> Get your own *FREE* website, *FREE* domain & *FREE* mobile app with >> Company email. >> *Know More >* >> <http://track.rediff.com/click?url=___http://businessemail.rediff.com?sc_cid=sign-1-10-13___&cmp=host&lnk=sign-1-10-13&nsrv1=host> > > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/04/28980.php >
