Previous | Next --- Slide 42 of 66
Back to Lecture Thumbnails
Holladay

And we can assume this is okay (i.e. someone wont come read that x = 15 before we abort it) because we guarantee that this operation is atomic? And thus no one can come in and read that before we have finished?

carnegieigenrac

I'm not sure why the undo log has multiple spaces in it. As only the original value before the atomic section can be added back to memory due to an abort, isn't it the only value which needs to be recorded?

bpr

@carnegieigenrac, transactional memory tracks all of the memory locations accessed while in the atomic section, which requires multiple spaces.

BBB

@Holladay The x=15 is written in the L1D cache, which owns the line in an exclusive state. So in order for anyone else to read the value in x, they would have to issue a bus request to get the value from us. When we see the bus request, we can abort our transaction and send them the old value.

So other people can come and read x before we finish our atomic section BUT they have to ask us the data, so we can send them the original value while we abort our transaction.

ant

I think we are discussing the semantics here, and not the implementation specifics (hardware or software). The cache based hardware implementation discussed later in the lecture would be one way to implement it. One particular software implementation (of transactional memory, not eager versioning in particular) and an analysis of the same can be found here: http://dl.acm.org/citation.cfm?id=1366230.1366241&coll=GUIDE&dl=GUIDE