Priority is given to whichever thread commits first. This is why - in case 2, T1 is aborted when T0 tries to commit.

With priority given to the commit from one transaction, the livelock situation in Pessimistic detection was mitigated.

I'm still confused on case 4, in class Kunle said that we must check the intersection between the write-set of the committing thread and the read-set of the pending thread. However it seems that for some reason we are deciding to look at thread 1's write-set compared to thread 0's read-set, I don't get why this is correct order. It seems to me looking at thread 0's write-set compared to thread 1's read-set, then committing thread 0, and then moving ahead seems to also work. What I'm confused about is if the the bars in case 4 of thread 0 and thread 1 could be flipped and if that would still lead to a correct interpretation?

@sagoyal I think in case 4, T1 commits earlier than T0, and we always check when a commit happens. If T0 commits instead of T1, we would flip the bars and still be correct.

@sagoyal I think these were typos and not misunderstandings, but wherever you said "thread" I think you mean "transaction?"

For optimistic detection, are we assuming that our data versioning is lazy? (i.e. before a write commit, memory is completely in the uncommitted state). If not, isn't case 3 dangerous because T0 reads from A while T1 is writing to A?

Is an optimistic detection system even compatible with eager versioning? I know that this slide indicates that pessimistic conflict detection is sometimes called 'eager', and optimistic 'lazy', so is it safe to say that eager data versioning is meant to work with eager conflict detection and the same for the lazy protocols?

@haiyuem thank that makes sense, and @kevtan yes I meant transactions (thanks for catching)

If an ordering happens similar to case 4 when T1 always starts after T0 and ends before T0 and the pattern repeats, wouldn't T0 experience starvation? Are there any fairness mechanisms that can guard against this?

@chii I think you're right. Longer transactions like T0 are at a disadvantage compared to shorter transactions like T1 and are more likely to experience aborts and restarts, which could lead to starvation. One way people have solved this issue is to introduce a global lock that a transaction will acquire if it fails too many times so as to force it to completion.

@trip I think you're right that optimistic conflict detection isn't meant to work with lazy data versioning. It says on slide 51 that this combination is "not practical." I also think that it's generally true that pessimistic—or eager—conflict detection works well with eager data versioning and optimistic—or lazy—conflict detection works well with lazy data versioning, although this is not always the case. Again, slide 51 shows some implementations of hardware and software TM that mix and match various conflict detection schemes with data versioning schemes.

If we're using lazy (write-buffered) transactions, then a commit could potentially take a long time. Is there a contention manager here that ensures one commit executes in its entirety before another related commit can execute? I'm thinking about Case 3, where if blue somehow committed after green, it would be incorrect because blue's computations were based on the old value of A, but if green committed first, the value of A blue should have seen would be the new value.

Could we also pick to use do optimistic checking upto a certain number of writes? As the transaction grows in size, we may still not want to check on every rd/wr but some chunk of them to reduce the amount of wasted work. Esp if this is implemented over a cache coherence protocol, that seems like a nice balance of coherence traffic too.

A question I had which was not addressed during lecture: if we only check if (write set of committing thread) overlaps with (read set of pending thread), then it seems we don't detect a conflict when there are write-write conflicts.

when i say thread, i also mean transaction..