If the conflict detection for reads is optimistic, why does this algorithm perform validation in Step 2 of STM read?

In any case, the read-set will be validated during commit time (as seen in the next slide)

@pranil is it optimistic because it first performs the read then validates the read data (as opposed to the pessimistic write, which validates the data first and then does the write)?

Just want to confirm, for the STM read, based on the example in the next slide, I think we read if data is not locked (if locked, we stall), but do we validate the data right the way or do we wait until the end to validate the data? Example in the next slide is not clear on this.

This slide made a lot of sense to me and tied in a lot with the previous discussions on optimistic and pessimistic. Reads are not as likely to cause a conflict since there's no change to the actual state so it makes sense to leave as eager so that we can make forward progress. Writes are much more likely to create a conflict so to leave it as pessimistic makes sense so we can detect this conflicts as soon as possible.

In office hours, it was brought up that this slide is wrong. STM optimistic read should not be validating the read data until the final commit. So, the lines "Validate read data" should not exist

@juliewang, this is super interesting. Does this mean that in a STM optimistic read, the transaction only reads the memory location (if eager), adds to the read set, and then returns the value it read, and only at the very end of the transaction when committing does it go through and check for potential conflicts?

@narwhale, I think so, but this does not have to do with it being eager or lazy. Eager or lazy has to do with how the system resets the state when it needs to restart the transaction. Eager, writes to memory, saving the old value in a log. Lazy, writes to a write buffer, which is committed in the end (or not).