Replace readwrite protection with read protection #1631
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.
The mutex analysis collects two kinds of protection information: readwrite and write. The former is a subset of the latter.
This PR changes it to collect just read protection instead of readwrite. When asked for readwrite protection, the intersection is still taken to find mutexes that protect both all reads and all writes.
I hoped the
protection-read
privatization could slightly be improved by using read-protection instead of readwrite-protection for its extra check, but that didn't work out. As-is this is more of a refactoring/cleanup: analysis results aren't really affected, although the read-protection sets can be seen in g2html.While changing that I realized we currently use
write:bool
in two different ways:write=true
means write-protection andwrite=false
means readwrite-protection.write=true
means a global write andwrite=false
means a global read (only!).I don't think this causes any bugs but it's still rather confusing because there are no readwrite accesses to globals (separate read and write access events are emitted).
As-is this PR makes things more consistent and correct, although readwrite accesses are never emitted, so this could be encoded more precisely with polymorphic variants.