libera/#sicl - IRC Chatlog
Search
8:41:55
moon-child
I think this might mean that simply recohering on a fence is sufficient. Alternately, it may mean that, when a given thread fences, it should interrupt all of the threads whose nurseries it has decohered and tell them to recohere
8:42:40
moon-child
but then I think there might be issues with transitivity--t1 serialises with t2, and t2 decohered t0; now when t1 fences, it doesn't know to tell t0 to recohere--so maybe not
8:52:22
moon-child
I'm starting to think just recohering on fence is sufficient. If t0 performed some side effects and then fenced, and t1 fenced and then attempted to observe those side effects, it should be guaranteed to succeed if t0's fence happened before t1's fence. But if that's the case, then t1 will be sure to observe those effects at that point, since it recohered as part of the fence
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