1. Transactional Memory: Architectural support for lock-free data structures
Maurice Herlihy and J. Eliot B. Moss,  ISCA '93
Proceedings of the 20th annual international symposium
on computer architecture
Presented By: Ajithchandra Saya
Virginia Tech

2. Outline WHY – The NEED WHAT – The solution My opinion
Transactional memory – Idea
Architectural support
Cache coherency Mechanisms
Cache line states
Bus cycles
Working
Simulation Results
Positives
Extensions
Current work
Conclusions
My opinion

3. WHY - NEED Increasing need for concurrent programs
Growing shared data access
Conventional locking mechanisms
Priority Inversion
Lock convoying
Hard to write concurrent programs
Data races
Deadlocks

4. Solution
LOCK-FREE SYNCRONIZATION

5. Transactional Memory
Multiprocessor architecture support intended to make lock-free synchronization easy and efficient
Extension of cache coherence protocols

6. IDEA
TRANSACTIONS
Finite sequence of machine instructions executed by a single process
Satisfies two important properties -
Serializability
Atomicity
Analogous to transactions in conventional database systems

7. IDEA Contd… Transactional primitives For memory access -
Load Transactional (LT)
Load Transactional Exclusive (LTX)
Store Transactional (ST)
Read Sets, Write sets, Data sets
For manipulating transactional states -
Commit
Abort
Validate

8. IDEA Contd … Example A simple memory read and update LT VALIDATE ST
COMMIT
If (2) or (4) fail, try again from step (1)

9. Architectural support
Extension to cache coherence protocol
If access conflict can be avoided then transaction conflict can also be avoided
Current cache coherence mechanisms –
Snoopy cache (Bus based)
Directory based (network based)
Separate caches
Regular cache – Direct mapped
Transaction cache – Fully associative

10. Cache line states

11. Bus cycles

12. Snoopy cache working
Memory responds to read cycles only if no cache responds
Memory responds to write cycles
Snoops bus address lines
Ignores if not interested
For regular cache –
T_READ, READ - Returns value
if valid -> valid
If Reserved, Dirty -> valid
For T_READ -> invalidates
RFO/T_RFO – Returns value and invalidates

13. Snoopy cache working For transactional cache TSTATUS False: True:
Behavior same as regular cache
Ignore tags other than NORMAL
True:
T_READ – returns value
Others – Returns BUSY

14. Working
Transactional operation modifications are made to XABORT tags only
Two copies of cached items
XABORT
XCOMMIT
COMMIT
Success
Failure
XCOMMIT
Empty
Normal
XABORT

15. Working Contd… Processor flags Internally managed by the processor
TACTIVE
Indicates whether a transaction is active
TSTATUS
If transaction is active i.e. TACTIVE = true, then if TSTATUS
True - transaction is ongoing
False - transaction is aborted

16. Working Contd … Taking the previous example LT
Operations – LT, VALIDATE, ST, COMMIT LT
Data availability
Action
XABORT
Nothing
NORMAL
Mark as XABORT
Create another copy marked as XCOMMIT
T_READ
Two cached copies marked as XABORT and XCOMMIT
BUSY
Drop all XABORT
Change XCOMMIT to NORMAL

17. Working Contd … VALIDATE – Returns TSTATUS flag ABORT
True – Continues
False - Sets
TSTATUS = true
TACTIVE = false
ABORT
COMMIT – Returns TSTATUS flag

18. Working Contd … New data entry to cache
Replace EMPTY
Replace NORMAL
Replace XCOMMIT
Replacing XCOMMIT should write back current data to memory
XCOMMIT state is used to improve performance

19. Simulations Comparison 2 Software techniques 2 Hardware techniques
TTS with exponential backoff
Software queues
2 Hardware techniques
LL/SC with exponential backoff
Hardware queues
SETUP
Proteus simulator
Number of processors 1 to 32
Simple benchmarks

20. Counting Benchmark

21. Producer/Consumer benchmark

22. Doubly linked list Benchmark

23. Positives Uses same cache coherence and control protocols
The additional hardware support required only at primary cache
Commit/abort are operations internal to cache
Doesn’t require communicating with other processes or writing back to memory

24. Extensions Transactional cache size – software overflow handling
Additional primitives for faster updates
Smaller data sets and shorter durations
Adaptive backoff techniques or hardware queues
Memory consistency models

25. Current Work
HTM
Hardware transactional memory is dependent on cache coherency policies and platform’s architecture
Unbounded Transactional memory
HTM migration during process migration

26. Current Work Software Transactional Memory (STM)
Strong vs. weak isolation
Eager vs. lazy updates
Eager vs. Lazy contention detection
Contention manager
Visible vs. invisible reads
Privatization

27. Conclusions
Lock-free synchronization to avoid issues with locking techniques
It is easy and efficient as conventional locking techniques
Competitive/Outperforms existing lock based techniques
Uses current techniques to improve performance

28. Opinion Novel technique to avoid synchronization issues
Requires little hardware modifications
Extensions are useful to make it practically usable

29. Why did it take so long for transactional memory to catch the limelight ??
Authors coined the term in 1993
Paper cited 1726 times1
Citation graph
Source: Maurice Herlihy: Transactional Memory Today. ICDCIT 2010: 1-12
1 Google scholar citation count

30. The Gartner Hype cycle
Source: Maurice Herlihy: Transactional Memory Today. ICDCIT 2010: 1-12

31. References
Maurice Herlihy: Transactional Memory Today. ICDCIT 2010: 1-12
Publications by author trier.de/~ley/pers/hd/h/Herlihy:Maurice.ht ml
Transactional Memory Online web page at:

32. Questions ???

33. Thank you