In the case that we have multiple threads running on the same core, and they share the same cache, is this architecture able to ensure transaction semantics between the threads? What I think is this cache based HTM is assuming that different transactions at the same time are running on different cores. Am I thinking in the right way?
I think this method can also ensure transaction semantics between different threads on the same core, they can simply just check the shared RW bits and decide if there is a conflict.
@Khryl and @RX, perhaps the hardware prevents a context switch while performing a transaction.
@Khyrl, I'm not sure if that would work. How would you "simply check the bits"? Since a single transaction can write to/read from the same address more than once, it's not like the system can simply decide to abort when trying to write to/read from a value that's already had a transaction flag set. I think you'd need a way of knowing who set the bit.
I guess what Khryl means is that, given multiple threads on the same core, if a thread A is writing var X and has not committed, and another thread B wants to read/write to X, B can simply check the RW bits.
@Khryl I think in architecture it is done by hardware. Maybe it is too expensive to do this on software/system level.
If it is pessimistic, then multiple threads on the same core can check R/W bit to find the conflict and abort. If it is optimistic way, then like @jhibshma said, we need to know who set the bit.
in case of context switch, i think the transaction would get abort and restart; and if there is a conflict between two transactions in same core, one of them should just abort to avoid conflicts.