libera/#sicl - IRC Chatlog
Search
8:08:40
moon-child
hayley: hmm. If we use my approach for replication, then there should still be a contention counter to trigger minor gc, but it should be per-thread
8:09:17
moon-child
ie given n threads, there should be n*n contention counters, where the (i,j)th counter measures how many times thread i diddled objects in thread j's nursery
8:09:43
moon-child
that's a lot of space, esp. if threads are supposed to be really cheap. But it's probably pretty sparse. So, hash table?
8:13:45
hayley
I suppose so. How do we know when to trigger, if the contention counts are spread out though?
8:15:36
moon-child
across different threads? Hmm, my initial thought was that that's ok, since the work is also getting spread out. But maybe that's not right
8:17:29
moon-child
it may not be optimal in all cases, but is probably better since there's not so much contention, as there would be if it were just one counter per nursery
8:18:44
moon-child
my thought was that if thread i noticed it was poking thread j's objects a lot, it would interrupt thread j and tell it to gc. So it's the max of contention counts, not the sum
8:31:12
hayley
Sure. I'm still wondering how to implement a fence, which has to make sure that no writes happen concurrently with the fence (i.e. all writes serialise before or after the fence).
8:31:42
hayley
There is a simple way if we use locks, as we can just wait for every lock to be unlocked.
8:37:34
moon-child
ok ... I looked up the exact semantics of fences. A key point is that that a fence on thread x synchronises-with all accesses on thread x (fine), but other than that, only synchronises with _fences_ in other threads
8:39:57
hayley
It makes sense, if e.g. sequential-consistency operations fence, and we can't reorder around those.
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.