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?
Khryl
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.
jhibshma
@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.
zvonryan
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.
yikesaiting
@Khryl I think in architecture it is done by hardware. Maybe it is too expensive to do this on software/system level.
Allerrors
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.
yangwu
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.
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.