libera/#sicl - IRC Chatlog
Search
12:58:24
hayley
What does recohering entail for you? With my locking scheme, it would require waiting for all writes to finish. There was a similar issue with change-class with the SICL object layout and single CAS; the operation requires updating both class and rack pointers, which I couldn't make lock-free with only single CAS.
13:01:02
hayley
Intuitively it would appear a thread trying to wait for coherence could "help" and write a newer value in one replica to another, but it doesn't work (I forgot what order of events makes it go wrong, but TLA+ found one).
13:19:42
hayley
Why does our write barrier have to keep two copies in sync, actually? Can it not just follow the forwarding pointer and only maintain the global version?
13:21:03
hayley
Er, now I remember, because we'd need a similar read barrier then. Don't mind me being stupid.
19:50:39
moon-child
hayley: about change-class: there is double-word contiguous cas. cmpxchg16b on x86, casp on arm, it looks like there's something also on riscv
23:33:08
hayley
Thanks. I'm aware of double word CAS (but not that it also existed on ARM and RISC-V).
23:34:17
moon-child
I _think_ it's part of the base A extension on rv, but on arm it's an extension (lse), and only part of base as of armv8.1+? 8.2+? One of those. I don't know how widespread support for it is in practice
23:34:49
hayley
We can still have incoherent objects if the object hasn't been added to the list, I think.
23:36:22
moon-child
yes, but if you recohere at that point, then whatever triggered the recoherence event (fence, atomic load or rmw) is not ordered wrt the access that is currently decohering the object
23:37:57
hayley
So we only need fences to synchronise with fences, and a fence implies that a thread is done decohering objects.