Description
Under Using Strict Provenance, the standard library documents:
(Yes, if you’ve been using AtomicUsize for pointers in concurrent datastructures, you should be using AtomicPtr instead. If that messes up the way you atomically manipulate pointers, we would like to know why, and what needs to be done to fix it.)
(I've not been able to locate a discussion similar to the following, and assume that this is the best place to reply to that invitation—but please do point me elsewhere if not!).
Some concurrent algorithms (I am particularly thinking of some epoch-based memory reclamation schemes) solve the ABA problem by packing both a pointer and an integer (e.g. an epoch) into a single (double-word width) atomic variable (e.g. a 128-bit atomic, manipulated using cmpxchg16b, on x86_64 architectures).
To do this with the existing atomic types requires using the appropriate double-word width atomic integer (e.g. AtomicU128 on 64-bit architectures), and converting the relevant single-word width subpart to/from a pointer.
If such pointer may be to different allocated objects over the course of the algorithm, it clearly is not possible to derive provenance in those conversions via strict provenance's .with_addr() method (because any "base" pointer from which provenance is derived would also have to be updated atomically with any update to this atomic).
I am not sure what the best solution to this might be. Perhaps something like an AtomicDoublePtr<T, U> type or similar?