Under a optimistic conflict detection, since we only do the checking right before a commit, does that mean there is no need to monitor the cache coherence traffic and just compare the R/W bits?
patrickbot
@doodooloo, in the next example, we assume optimistic-lazy TM and we abort if there is an eviction. So I think we still monitor cache coherence even though we don't try to commit until the end.
yangwu
in eager versioning, we need one cache line to store updates, the other for undo logs;
but for lazy versioning, we only need 1 cache lines as write buffers
Richard
The scenario assumed by this slide is that two threads are from different cores. What if they are within one core, and being executed in an interleaving pattern in instruction granularity?
RX
If we use cache coherence to implement HTM, what if the working set in an atomic region can't fit into cache?
lol
@RX Then it's likely aborted. It could rollback to use a heavier non-transactional lock.
Under a optimistic conflict detection, since we only do the checking right before a commit, does that mean there is no need to monitor the cache coherence traffic and just compare the R/W bits?
@doodooloo, in the next example, we assume optimistic-lazy TM and we abort if there is an eviction. So I think we still monitor cache coherence even though we don't try to commit until the end.
in eager versioning, we need one cache line to store updates, the other for undo logs;
but for lazy versioning, we only need 1 cache lines as write buffers
The scenario assumed by this slide is that two threads are from different cores. What if they are within one core, and being executed in an interleaving pattern in instruction granularity?
If we use cache coherence to implement HTM, what if the working set in an atomic region can't fit into cache?
@RX Then it's likely aborted. It could rollback to use a heavier non-transactional lock.