We only keep one copy of a variable in the write buffer, right? (just like what is talked about in the class, the cache is the write buffer) It is not like there is a queue or something for the write buffer or the undo log, correct?
@zvonryan I think that is true, If you overwrite the variable to a new value during the transaction, that is the variable you want to become visible to other threads when you commit. Therefor you should only keep a single version of any variable.
So basically, in eager versioning, we write to memory right away where as in lazy versioning, we make sure that our write was successful before writing to memory? How do programmers determine which to use?
Lazy versioning delays writes to memory until the end of the transaction. Aborting can be done simply by clearing the write buffer, since no actual memory locations are updated yet. This makes aborting inexpensive compared to eager versioning.
Why would we ever use eager versioning to implement Transactional Memory. The semantics require the writes to not be visible till the commit hence I see absolutely no benefit of eager versioning. Can someone point out a use-case where eager versioning would make sense.
The semantics of eager version work well with pessimistic detection. Eager versioning is useful if you don't expect there to be lots of aborts, since commits are faster than commits in lazy versioning.