4 ms·
On A: temp = remote read of y; if (temp >=1 && x >= 1) A.x = A.x - 1; On B: temp = remote read of x; if (temp >=1 && y >= 1) B.y = B.y - 1; I simplif
by abadid 8y ago
On A:
temp = remote read of y;
if (temp >=1 && x >= 1)
A.x = A.x - 1;
On B:
temp = remote read of x;
if (temp >=1 && y >= 1)
B.y = B.y - 1;
I simplified the code a little by checking on the old value of x and y instead of the new one, but I could have written the code to check on the new value instead.
- j16sdiz 8y agoWe can't do this on a modern NUMA computer. Good luck trying across different system.
- lurker458 8y agoIs the cost of doing these remote reads worth the savings in this case ? After all to be correct, they need to run in the same transaction at the sending side and need to be persisted at the receiving side. Also, consider the effort if this gets scaled up to 10 cases (each node would have to do 9 remote reads)
- abadid 8y agoThey don't need to be persisted at the received side, but yes, there could be 9 remote reads if each of 10 shards are running code that may result in state-based aborts. Usually, however, only a subset of the shards run such code. But remember, 2PC requires 4 messages per worker (so 40 messages total in your example).
- lurker458 8y agoTrue, but it's O(n^2) complexity instead of O(n) complexity (1000 shards would lead to 1M reads instead of 4k) If they're not persisted at the receiving side, how does it handle a crash before committing on the receiving node ? Keeping previous versions indefinitely on sending nodes to permit requesting the old values doesn't work, so this introduces a time bound on how long a crashed node has to recover (granted, this could still mean weeks)
- abadid 8y agoThis requires a longer response that I have time write now. Please check back tomorrow night ...
- abadid 8y agomagicalhippo asked a similar question both with regard to complexity and garbage collection. I think it is best to combine these threads, so please see my response there ... https://news.ycombinator.com/item?id=19003212 https://news.ycombinator.com/item?id=19003212
- oggy 8y agoI don't understand your point about only a subset of shards running code that may abort. Since we are talking about transactions, if there is even a single shard S that may abort (based on its state), then all other shards must also abort when S aborts. Which would imply that all other shards must also read the state of S before they commit. Am I missing something?
- pacala 8y agoInteresting. This assumes there is a way to do consistent remote reads, that is some way to implement B.read(value=y, tx=T). Additionally, this works without using a global sync point, as per your other message. Naive implementation: * B just blocks the read call until T is ready for execution, then returns the value of y. * The coordinator C pushes the transactions to both A and B until they independently ACK, so B never blocks forever. * Assuming serializable A and B. Would be interesting to see how this performs compared with vanilla 2PC. The one downside I see is that if B vanishes for a prolonged amount of time, A is stuck waiting on its read call without a mechanism to drop the distributed transaction T and go on with its other duties.
- abadid 8y agoI understood and agree with all of your stated assumptions. However, I didn't follow your naive implementation. I would definitely caution against using a coordinator.
- pacala 8y agoThe transaction must enter the system somewhere. The 'coordinator' is that entry point, with a durable log so we don't inadvertently lose the transaction. It's only job is to push the transaction to all the workers involved.