Skip to content

Conversation

@chrisvest
Copy link

The soPrev method implies that it's making a store with RELEASE semantics, but it was doing a plain store.

This changes the method implementation to store with RELEASE, matching its naming convention. Since is also a more correct counterpart to the only loads of this field, which are always done with volatile memory semantics.

It's not clear to me if this fixes a real issue on architectures with weaker memory orderings than x86.

The soPrev method implies that it's making a store with RELEASE semantics, but it was doing a plain store.

This changes the method implementation to store with RELEASE, matching its naming convention.
Since is also a more correct counterpart to the only loads of this field, which are always done with volatile memory semantics.

It's not clear to me if this fixes a real issue on architectures with weaker memory orderings than x86.
@chrisvest
Copy link
Author

FYI @franz1981

@franz1981
Copy link
Collaborator

franz1981 commented Nov 30, 2024

Thanks @chrisvest for looking into this, so...
According to

and

In both cases there are other operations which release the prev value (along with other states) hence it could be that the prev store release could be a plain one too: this means that the method name was wrong, likely.
I have re-read my own impl to make sure of this, but I see that

too is not required to be a load acquire but just a plain one, since the queue logic assume that the prev values are released by

@franz1981
Copy link
Collaborator

And indeed I already found this but forgot to merge it, see #309

@chrisvest
Copy link
Author

Five years ago, lol. Yeah, maybe #309 need to be brought over the finish line.

@chrisvest chrisvest closed this Dec 1, 2024
@chrisvest chrisvest deleted the patch-1 branch December 1, 2024 21:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants