As a recap from lecture, in Case 1, we're not seeing any concurrent writes/reads to the same variable, so it's all a success. In Case 2, we know that T0 plans to commit wr changes to A, and once it does, the optimistic detection will let T1 know (who already got to work with A as a read value) that it ought to restart and re-read A. Meanwhile, in Case 3, we see that T0 reads the value of A before T1 gets started and T1 later writes to T1; this illustrates the success case with no abort required as T0 reads A safely before it is written with a commit by T1. Lastly, in Case 4, we see forward progress happening when T0 reads and writes to A, but T1, in a smaller time span will read and write A with a commit. In this case, T0 is told to restart and rd the newly committed value of A and then write something new. Note: in lecture, Kavyon stipulated that this was arbitrary: it could've been that T0 finished before, in which case T1 might've started after T0's commit!

@ecb11, for case 2 is it more like writes get priority over reads, so we'll have to commit that first before reading?

@ckk In slide 48 it says "On a conflict, give priority to committing transactions", so in case 2, T0 is the committing transaction so T1 must yield to it and abort.

Why don't we just automatically switch between optimistic and pessimistic detection based on the number of concurrent transactions?

We only abort if the committing thread's write set overlaps the read set of the other. What was initially confusing to me was that I thought the read/write set that we considered was the final one throughout the process, but only after we read/write, do we add it to the set

There are some hybrid optimistic/pessimistic software TM systems from Intel as I believe was mentioned in the lecture. However, in those schemes, they were implemented as optimistic read/pessimistic write.

In case 4, what is the point of T0 restarting? Is it because it has memory that is out of date so it needs to access it again to gain T1's write operation?

@alexder - my understanding is that T0 aborts because T1 as the committing transaction wins and a check is performed for all transactions that may contain a read/write to A (since T1 contains A in its write set). The optimistic implementation causes an abort to occur for all other non-committing transactions.