libera/#sicl - IRC Chatlog
Search
21:55:23
hayley
Another dropped message apparently. How are obsolete instances detected again? I wonder if you can update the class first and use obsolete instance detection to spot a CHANGE-CLASS in progress.
21:56:56
hayley
So an object could have values <old class, old rack>, <new class, old rack>, <new class, new rack> and we want to detect the second.
23:58:23
Bike
obsolete instance is detected by mutating all relevant generic functions to hit the updater on objects with the old stamp
23:59:46
Bike
but i think a change-class concurrent with a dispatch isn't the problem, so much as doing two change-classes concurrently
1:07:59
hayley
I get that CHANGE-CLASS has to be safe, but is it expected that it will succeed with concurrent accesses and/or other CHANGE-CLASSes, instead of signalling if it detects concurrent modification (something like Java collections)?
1:08:30
Bike
i think signaling an error would be fine. the problem is a silent failure leaving objects in an inconsistent state
1:09:56
Bike
you know, like your usual thread 1 alters class -> thread 2 alters class -> thread 2 alters rack -> thread 1 alters rack thing
1:10:55
hayley
Hm, but then to be safe, we require some kind of safety test when getting the rack for an object in any normal accessor or STANDARD-INSTANCE-ACCESS or whatever else.
1:12:10
Bike
easiest thing would probably be to cheap out and e.g. have a couple global locks selected by a hash and grab them during change-class
1:12:25
hayley
Concurrent CHANGE-CLASS can be sort of handled though; either thread 2 notices that it failed the class update and either waits or updates the rack itself, or it signals.
1:14:53
hayley
Well, thread 2 would spin (possibly helping, to make it wait-free) until it sees the object in a consistent state, then reads the class....no, it can't atomically read both class and rack pointers, so it can't test for consistency.
1:17:39
hayley
If the object is updated between reading the class and rack, then later updates would fail and the process would start over (or signal).
1:36:56
hayley
"System checks that Alice has enough money. $1,000 is deducted from her account. Eve smashes in the server with a baseball bat. Bob never receives the money. $1,000 has completely disappeared from the system. The SEC shuts you down for fraud."
1:59:06
hayley
That said, I haven't figured out how to assert that the object is consistent in the end, but I was a bit more confident in that to start with.
2:08:15
hayley
If I remove the part where we help with updating the rack if we notice it is inconsistent w.r.t the class, then my invariant (either some thread is in CHANGE-CLASS or the object is consistent) holds though.