-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix warnings #193
Merged
Merged
Fix warnings #193
Changes from 1 commit
Commits
Show all changes
20 commits
Select commit
Hold shift + click to select a range
d49337c
update pybind submodule
N-Maas 42b6d9b
fix null pointer warning
N-Maas 88bd0d9
update googletest submodule
N-Maas e146a01
fix for coarsener
N-Maas a971d48
make coarsener code slightly easier to follow
N-Maas 42de03e
fix some clang warnings in tests
N-Maas 41f6899
replace deprecated `TYPED_TEST_CASE` with `TYPED_TEST_SUITE`
N-Maas ffa0215
suppress clang warnings for growt
N-Maas c599dd0
remove unused variable
N-Maas 5a0ae5a
suppress some clang warnings related to gtest
N-Maas a7fb47b
remove warning suppression by fixing the warning
N-Maas 6bf2bd5
more unused variables
N-Maas 97632af
fix for mtx converter
N-Maas 340babd
one more unused variable
N-Maas 6adab00
fix some more warnings
N-Maas eb34ab1
ouch
N-Maas 45a7015
remove members only used by assertions if assertions are off
N-Maas 2702283
unused variable
N-Maas cc088ca
specify memory orderings for coarsening code
N-Maas 76bbeaa
update comment on memory ordering
N-Maas File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a compare-exchange, the memory ordering should be acquire
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm, for what reason? This is absolutely not generally true. You can't just map operations to orderings, that is not how memory ordering semantics work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't some of the loads and stores in the locked state be allowed to moved before the CAS? Is that why the load on line 389 has acquire ordering? Does that prevent this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the accesses we need to be careful about are loads and stores of
cluster_ids
. New cluster IDs are written by the "owning" thread of the according node in thejoinCluster
operation. Cluster IDs are read either during conflict resolution (line 440) or when the state ofv
is already MATCHED (line 393). So in these two cases, we need to establish a happens-before relationship between the reading thread (lets say t_u) and the writing thread (t_v).Line 393: Since u is owned by t_u, no other thread than t_u has performed a write on
matching_state[u]
. Thus, using acquire semantics for thecompare_exchange
wouldn't do anything here, since there is nothing to establish a happens-before relationship with. However, t_v has updatedmatching_state[v]
to MATCHED after updating the cluster ID. What we need is therefore a happens-before relationship with regards tomatching_state[v]
. This is achieved by the release semantics in line 448 (as well as 403/430, though I think the release semantics aren't even strictly necessary there, since the cluster ID does not change) and the load on line 389 with acquire semantics.Line 440: Same principle, in this case the acquire semantics on
matching_state[v]
are provided by the load in line 432.Now, of course this does not provide any ordering guarantees for the accesses to
_matching_partner
(e.g. line 384). However, as discussed before, acquire semantics on thecompare_exchange
wouldn't help with this either, since there is nothing to synchronize against (I guess if we want that ordering we could use release semantics for the write in line 384). Luckily, the conflict resolution code does not need any ordering guarantees, since it just loops until a consistent state is detected. Only when the conflict is resolved and writes happen we need the acquire/release semantics.So the summarized argument for the correctness is that (a) all accesses to
cluster_ids
are synchronized via acquire/release semantics on the read/write whencluster_ids[v]
changes state to MATCHED and (b) we don't need ordering guarantees for accesses to_matching_partner
.Of course there is also
_cluster_weight
, but here we just accept that a cluster might get too heavy if a race condition happens. To fix this we would need acompare_exchange
loop injoinCluster
, which we probably don't want.