4 ms·
In my experience, in practice, it usually isn't that hard to figure out what people meant by a READ/WRITE_ONCE(). Most common cases I see are: 1. I'm sharing
by bjackman 9mo ago
In my experience, in practice, it usually isn't that hard to figure out what people meant by a READ/WRITE_ONCE().
Most common cases I see are:
1. I'm sharing data between concurrent contexts but they are all on the same CPU (classic is sharing a percpu variable between IRQ and task).
2. I'm reading some isolated piece of data that I know can change any time, but it doesn't form part of a data structure or anything, it can't be "in an inconsistent state" as long as I can avoid load-tearing (classic case: a performance knob that gets mutated via sysfs). I just wanna READ it ONCE into a local variable, so I can do two things with it and know they both operate with the same value.
I actually don't think C++ or Rust have existing semantics that satisfy this kinda thing? So will be interesting to see what they come up with.
- deschutes 9mo agoIt sounds like std::atomic_ref<T>::{load,store}(relaxed) to me. 1. ad-hoc atomicity with ref 2. no ordering https://godbolt.org/z/4h893P7hG https://godbolt.org/z/4h893P7hG
- bjackman 9mo agoI believe that lets the compiler reorder the accesses. So this would be fine for my second example but it would be broken for my first example. ({READ,WRITE}_ONCE() only lets the compiler reorder the accesses if they happen in the same C statement). I think C++ doesn't have an equivalent because it just doesn't make sense as a primitive in very many environments.