I just noticed that Eager + Optimistic for Hardware TM Systems is not practical. Why is this the case?

Same question^ Is it because doing so would be inefficient and even incorrect? If we eagerly write to memory before a transaction completes, but only check for other transactions when committing, then the previous value that's written may be overwritten by other threads? Would there be a way to recover that?

I believe Eager + Optimistic is not used in hardware because if a transaction writes directly to memory, future transactions will read the updated value from memory even if conflicts exist - this leads to expensive restarts and use of the undo log to reset memory. However, I'm not sure why this is specific to hardware - does anyone know why software systems can handle Eager + Optimistic without running into the same problems?

@sanjayen not sure if software systems can handle that case. Although the case is deemed impractical for hardware TM systems, if you see that the only combination mentioned in Software TM systems related to this is- Eager + optimistic(rd)/pessimistic(wr)

Do different HW TM systems have the same overhead in terms of implementation? (Not in terms of how often transactions stall/abort)

@alanda I would assume so, as different HW have different optimizations/memory latency etc. I would think that the difference comes mainly from latency, and not large implementation differences however.