Previous | Next --- Slide 44 of 64
Back to Lecture Thumbnails

It seems like in applications with a lot of parallelism eager versioning is preferable to to lazy versioning because you're more likely to have a commit succeed than fail. In cases of high contention, you might not want to use transactional memory anyways because you'll have to roll back a lot. I am correct to assume this?


@FarmerScrub, I believe you're correct, but there are situations when lazy-versioning would be better than locking. For one, it could be easier to implement, and if contention is common but not pervasive, it may admit more parallelism than locking and fewer aborts. And the fault tolerance is very important for systems tracking important data (bank accounts, etc).


At first glance, eager versioning may be preferable to lazy versioning, since the motivation for TM is optimizing for common situations (less contended memory resource) in the first place, so the property of fast committing may be desired. While a problem of eager versioning is its complexity to implement, due to the fault tolerance difficulty. Also, I think the lazy versioning may be more easily adapted to a contended situation, where abortion is more often in the case.


During a commit can you change the order of writes in the write buffer to get better bandwidth?


It seems like hardware eager versioning should be able to reuse existing systems for undoing speculatively executed instructions and lazy versioning should be able to also reuse the existing write-buffer. Is this actually done on some systems?


@perpendicular I think that as long as a transaction doesn't write to the same location twice with different values out of order writes should not cause a problem. I would hope the TM system would optimize over multiple writes to the same location such that only one write is performed on commit.