another might be to force aborted transactions to wait for the transaction which caused them to abort to complete, if the conflict was a write-write conflict.
Pessimistic detection involes shouting across the bus every time you perform a read or a write. This is a much safer approach if your primary concern is atomicity, and is possible more performant than optimistic detection is the cost of a bad read/write is incredibly high. The downside is that you have a lot more traffic across your bus.
In case 2, T1 stalls for a W->R (-> means happens before) transaction whereas in case 3, T0 aborts for a R->W transaction. Looks like, for a R->W or W->W the conflicting transaction aborts but for a W->R, the transaction just stalls. Are these the rules? So, in the pessimistic case, is the Write a write through or write back to memory? In either case, the cache coherence should take care of the read by A, no? So why should T1 stall?
@shivalgo, I think those are just rules, yes. Anything that is followed by a W should be aborted (hence R->W and W->W both abort the earlier transaction) because there's a chance that either the other transaction read a value that was just about to be modified, or is writing a value but which would be overwritten almost immediately.
I think also that the writes that are happening here are to the processor caches, and not write-through. You're right that in case 2, cache coherence should "take care of" rd A by T1. But, I think more specifically, it is the wr A by T0 that does the actual error handling by announcing that it now has A in a dirty state, which means that any other transaction that wants to read A has to stall.
I have a question though. Why is it in case 3 that T0 is allowed to restart before T1 has committed? Is this just a rule that restarts that have been triggered by a W->R can just restart IMMEDIATELY? Why not just restart when T1 has committed since T0 would be stalling till the end of T1 anyway?
In Case3 T0 restarts when T1 writes to A. But when it restarts, the readA operation stalls until T1 is committed. So its essentially equivalent to restarting T0 after T1 commit. But restarting T0 early and stalling it till T1 commits is how the contention manager in the example works.
So is it just better to generally not use pessimistic writes? As it seems that this case would likely happen often.....
Please log in to leave a comment.
One way to avoid Livelock in case 4 would be to force a transaction to wait a sufficient amount of time for the other interrupting transaction to finish.