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
Remove Atomic.h #9707
Remove Atomic.h #9707
Conversation
The STL has everything we need nowadays. I have tried to not alter any behavior or semantics with this change wherever possible. In particular, WriteLow and WriteHigh in CommandProcessor retain the ability to accidentally undo another thread's write to the upper half or lower half respectively. If that should be fixed, it should be done in a separate commit for clarity. One thing did change: The places where we were using += on a volatile variable (not an atomic operation) are now using fetch_add (actually an atomic operation). Tested with single core and dual core on x86-64 and AArch64.
|
You absolutely love to see it =). I think with this, we finally have most of the volatile occurrences removed from the codebase (aside from one in DSP code off the top of my head) |
|
I've actually only removed 7 out of the 16 volatiles in |
| { | ||
| Common::AtomicStore(_reg, (_reg & 0xFFFF0000) | lowbits); | ||
| reg.store((reg.load(std::memory_order_relaxed) & 0xFFFF0000) | lowbits, |
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.
Just wondering, is this still atomic in the end (with a seperate load then store)?
Then again, thats what the old code did, so same issue there...?
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.
This is indeed not atomic. I mentioned this in the PR description.
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.
Fair enough, I read that and dismissed it from my head while looking at LowPart/HighPart (only remembering the Low/High part).
The STL has everything we need nowadays.
I have tried to not alter any behavior or semantics with this change wherever possible. In particular,
WriteLowandWriteHighinCommandProcessorretain the ability to accidentally undo another thread's write to the upper half or lower half respectively. If that should be fixed, it should be done in a separate commit for clarity. One thing did change: The places where we were using+=on a volatile variable (not an atomic operation) are now usingfetch_add(actually an atomic operation).Tested with single core and dual core on x86-64 and AArch64.