(3.5.3) LogTM

Kevin E. Moore, Jayaram Bobba, Michelle J. Moravan, Mark D. Hill and David A. Wood. LogTM: Log-based Transactional Memory. HPCA 2006. IEEE Xplore link


Version Management
>> Eager : in place on store
>> Lazy  : temporarily leave old value in place 

Conflict detection
? overlap between write set of trans 1 with write/read or trans 2,3,4...
>> Eager : detect offending loads/stores immediately
>> Lazy   : when transactions commit.

Lazy, Lazy : OCC DBMSs, Stanford TCC
Lazy conflict, Eager Version : None (zombies)
Eager, Lazy : MIT LTM, Intel/Brown VTM (conflict using cache conflicts)
Eager Eager : MIT UTM, CCC (conservative concurrency control) DBMSs, LogTM

Log TM

Version management
>> per-thread before image log in cacheable virtual memory  
>> Last in first out undo.

Conflict detection
>> coherence request to directly
>> Directory responds and possibly forwards the request to one or more procs
>> each responding processor examines some loacl state to detect a conflict
>> the responding processors ack (no conflict) or nack (conflict) the req
>> the requesting processor resolves any conflict
??  What if cache block is evicted?     
>>> directly still forwards to all "appropriate processors"
>>> Go from M to sticky M [on overflow bit set, check if even sticky M violation happened] 
>>> Lazy cleaning of sticky state (when overflow is not set and its sticky => it was sticky sometime ago, not now) 


From Prof Hill's talk in MSR :       
What happens when conflict happens ?
     wait >> could lead to deadlock
     abort >> could lead to livelock
     possible soln >> contention manager (requesting processor traps to software contention manager)