search

colinjfw / read-copy-update

Provides a read-copy-update locking primitive
MIT License
1 stars 1 forks source link

Safety of Relaxed memory ordering #1

Open spangaer opened 4 months ago

spangaer commented 4 months ago

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 a Release store requires an Acquire associated load to achieve (platform independent) memory safety?

Am I missing something?

spangaer commented 3 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.