An idea to avoid livelock would be to either assign a priority to each transaction, or to tiebreak randomly. For example, we could decide on a rule that even-numbered transactions should go before odd-numbered once in the case where both are writing to the same address. Another way would be to structure the implementation by guarding simultaneous writes by a lock, so only one transaction would be able to acquire the lock and the other would be forced to wait until the first yields the lock.

Another idea to avoid deadlock, if there's a conflict for two transactions writing to the same address could we just give priority to the one that came first and restart the second one? Ideally we could do a stall->restart, so that we don't keep restarting

I have a quick question regarding the abort part: when using the abort scheme, we still need to stall after we restart T0's work. Why is that the case? Since we need to stall any way, isn't using the stall scheme better?

What happens if there're more than 2 transactions happening at the same time? Does each T needs to broadcast to all other Ts for this scheme of conflict resolution? That quickly grows to O(n^2) additional communication which would impact performance?

In the lazy scheme, do we need to abort when T1 reads something in T0's write set? Since this change has not been committed, why can't it just read the value from memory?

I'm struggling to see the difference between Case 2 and Case 3. In case 3 why can't T0 just restart and stall like in case 2. Does the abort in case 3 refer to the restart or does it mean that both the transactions fail?

If we know that T1's working set has A, why does T1 not abort on the first rd/wr to A from T0? It appears that T1 is also already running by the green bar

@evs I think stall in case 2 means T1 waits to see T0 commits so T1 knows the value it reads is correct before proceed. In case 3, T0 reads before T1 write the value. Since in this case we assume write operation has priority, T0 needs to restart to get the correct value from T1

I also had the same way of thinking at @ggomezm. If we let the write that came first to complete, while making only the other conflicting write to restart, seems like it would all complete faster and avoid a livelock.

I wanted to say this in lecture if I attended it live but basically, in the pessimistic detection model the write in a write conflict is always right! Whew Now that it's off my chest I'll say that I also had the same idea of adding nuance to our policy such that in the case of a write-write conflict we give priority to the writer that already finished writing and stall the other thread waiting to write.

Is there special hardware to help make transactions faster? It feels like there would be a lot of bus messaging to do this checking. What operations are delegated to the contention manager vs the threads?

Could we just declare a "pecking order" of which CPU core wins, physically, in silicon? It could be completely arbitrary and still work just fine, right?

During a stall (such as in case 3), do we re-issue the read?

Also, why in case 4 do we not just stall the write in transaction 1? It seems like generally we want to create a system that stalls over aborting because in an abort we lose work that has been done, which could end up being an expensive choice.

If we ever have more than 2 threads, can there be a case of deadlock? I'm wondering if all threads are writing and reading to a variable there must be a case where we get stuck.

I'm also curious about the hardware optimizations that help make these conflict detections fast. In particular, is there specialized hardware that helps with set comparisons (for comparing read/write sets?)

when rd follows wr, rd stalls. when wr follows rd, rd restarts.

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.