Open spangaer opened 4 months ago
Since my original writing I can elaborate on the statement.
If my understanding is correct, you'd get away with this on strongly ordered hardware memory models (x86/AMD64). Likely even on weakly ordered memory models which respect data dependency (ARM).
It could however get tricky on "fully" weakly ordered memory models, possibly RISC-V?
The C++ memory model intends to be valid for all possible scenario's so must abide to the weakest possible model. In turn this means that writing semantically correct and by extension portable code needs to do the same.
So if I'm not mistaking that would mean doing this pointer load with Acquire
ordering.
Note that I've run a version of your RCU code doing just that on AMD64 hardware and haven't observed a performance impact. While I must admit I haven't been very thorough at that, given the stronger implicit memory related guarantees, it doesn't seem that surprising either.
Hi Colin,
While studying the Rust memory model and as sidestep read-copy-update I stumbled upon your crate.
It does show remarkable performance compared to some other shared state techniques I had a stab at.
What I can't seem to get my head around is why this load would safely allow
Relaxed
ordering? https://github.com/colinjfw/read-copy-update/blob/fadcb69124c1535232ba9a1805dc10c252aeee40/src/lib.rs#L241 All documentation I consult on the C++20 memory model seems to indicate that aRelease
store requires anAcquire
associated load to achieve (platform independent) memory safety?Am I missing something?