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