The Argo atomics do not install the data in the local cache #20
Comments
|
It should be noted that the failure of this test case is another bug, but failing in this particular assertion uncovered that atomic accesses are not stored in the cache. |
ioanev
pushed a commit
to ioanev/argodsm
that referenced
this issue
Apr 11, 2022
This commit modifies some atomic tests in backendTests to use `atomic::load` rather than pure memory loads as per issue etascale#20.
ioanev
pushed a commit
to ioanev/argodsm
that referenced
this issue
Apr 11, 2022
This commit modifies some atomic tests in backendTests to use `atomic::load` rather than pure memory loads as per issue etascale#20.
ioanev
pushed a commit
to ioanev/argodsm
that referenced
this issue
Apr 11, 2022
This commit modifies atomic tests in backendTests to use `atomic::load` rather than pure memory loads as per issue etascale#20.
ioanev
pushed a commit
to ioanev/argodsm
that referenced
this issue
Apr 11, 2022
This commit modifies the atomic tests in backendTests to use `atomic::load` rather than pure memory loads as per issue etascale#20.
kostis
pushed a commit
that referenced
this issue
Apr 13, 2022
This commit modifies the atomic tests in backendTests to use `atomic::load` rather than pure memory loads as per issue #20.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the MPI backend, when an Argo atomic instruction reads or modifies some data, it does an RDMA operation to access the data. The Argo coherence is bypassed and the data are never installed in the local cache. One would expect the data to be installed in the cache after an atomic access.
Relevant issue: The
loadOnetest fails in the secondASSERT_EQ(ASSERT_EQ(i_const, *_i);) even through thewhileloops before it checks for the exact same condition. The only difference is that thewhileloop uses an atomic instead of a normal load.The text was updated successfully, but these errors were encountered: