Does hardware TM system also allow different optimistic for rd and pessimistic for wr, or rd/wr must either both be optimistic or both be pessimistic?

As discussed in class, the eager + optimistic implementation of hardware TM systems is impractical because it makes it very hard to ensure isolation. In particular, it would be very challenging and impractical to try and abort things that had already been written to memory.

To follow up on @nickbowman's comment, Eager data versioning usually keeps an undo-log in case of write conflicts, so the undo log in theory allows one to revert the memory addresses to previous values. My understanding for why this is impractical in hardware is because of the cache coherence traffic cost.

In particular, imagine two transactions both repeatedly writing to x. With eager + optimistic, both transactions will continue until they commit. This means that one thread writes to x, invalidating the other thread's cache line. Then the other thread writes to x, invalidating the first thread's cache, etc. This continues back and forth until one (or both?) commits, where they realize there's a conflict. They can then go through the undo log to write back old values of x, but all the previous writes, and more importantly the previous cache BusRdX, are all wasted. This gets really bad if the number of processes is much bigger than 2.

Would love an instructor to elaborate on this!

Eager + optimistic is impractical is because it very difficult to abort things already written to memory.

Prof Kunle mentions in lecture that its easy to layer a eager + pessimistic transactional memory system on top of a MESI cache coherence protocol.

Why is is that Eager + optimistic is impractical again? I understand that it may be difficult to "abort things already written to memory", but isn't that with Eager versioning, we have undo-logs, so that we can just revert step by step using the undo logs?