An Introduction to Software Transactional Memory

Alessia Milani

Labri, Bordeaux

Popularizing Concurrent Programming

• A multi-core revolution is underway• Exploit the power of concurrent

computing, by restructuring applications• Devise scalable concurrent programs is

hard…unless good abstractions :☞ Transaction

2

Transaction

A transaction is a sequence of operations by a single process on a set of shared data items (transactional objects) that ends

Either by committing : all of its updates take effect atomically

or by aborting : has no effect (typically restarted)

3

4

Transactional Memory (TM)

• To simplify : Just wrap (sequential) code in begin / end transaction

• TM synchronizes memory accesses so that each transaction seems to execute sequentially and in isolation

begin-transaction-------------------------------------------------------------end-transaction

Implementing Transactional Memory

• TM was originally suggested as hardware platform [Herlihy and Moss 1993]

– HTM is in today hardware platforms, e.g. Intel, IBM, Sun

• Purely in software : – First Software Transactional Memory (STM) only

for static transactions [Shavit & Touitou 1995]

– First dynamic STM [Herlihy, Luchnagco, Moir and Schrer 2003]

• Hybrid schemes (HyTM) that combine hardware and software [Moir et al. 2006]

Implementing Transactional Memory in Software (STM)

• Data representation for transactions and data items using base objects

• Algorithms for operations on data items, applying primitives to base objects– registers, CAS, DCAS

Asynchronous processes execute these algorithms to execute the operations of the transactions

base objects read

read

write

TryCommit

…

begin-transaction

end-transaction

Algorithms

6

7

3 levels of abstractions

• Transaction

• Operations – on data items: E.g., read

and write– tryCommit / tryAbort

• Primitives on base objects (registers, CAS…)

read write tryCread

STM algorithms

Main Techniques

8

Back to TM ConsistencySerializability: committed transactions

appear to execute sequentially

begin-Tx

read write

write writeread read

TryC

TryC

Commit

read

begin-Tx Commit

begin-Tx

write writeread read TryC

Commit

read write TryCread

begin-Tx Commit

Back to TM ConsistencySerializability: committed transactions

appear to execute sequentiallyStrict serializability: also preserves the

order of non-overlapping transactions [Papadimitriou 1979]

Opacity: even transactions that later abort are (strictly) serializable [Guerraoui, Kapalka POPL 2008]

Much more …

serializability

strictserializability

opacity

Conflicts

• Two concurrent transactions have a conflict if they access the same data item and at least one of these accesses is a Write operation.

• Two transactions that cannot be serialized have a conflict. (The converse is not true)

11

p1

begin-Tx

Read(x)0

Read(x)0

Commit

begin-Tx

Write(x)1

Write(x)2

Commit

p2

p1

begin-Tx

Read(y)0

Read(x)0

Commit

begin-Tx

Write(y)1

Write(x)1

Commit

p2

12

Design approaches

• Deferred/Direct updates : operate on local copies of the data items & install changes at commit/ Modify in place, roll back on abort

• Detect conflicts– Commit time– Encountering time

• Resolve a conflict either by aborting one of the conflicting transactions or by waiting/helping it to complete– This depends on the progress you want– Contention manager

13

Contention Manager Strategies

• Priority to– Oldest?– Most work?

…

• None Dominates• Lots of empirical work but formal work in

infancy

Progress for TM• Lock-free TM

– Wait-freedom : each non-faulty process completes (successfully) its transaction within a finite number of steps

– Obstruction-freedom : a process running solo eventually commits its transaction

• Lock-Based TM– Weakly progressive: a transaction aborts only if it has conflicts

[Guerraoui, Kapalka POPL 2009]– Strongly progressive: at least one of the transactions involved in the

conflict commits– Multi-version permissive: only writing transaction that conflicts with

another writing transaction aborts[Perelman, Fan, Keidar PODC 2010]

Read-only transactions always commit

STM algorithms

Two Case Studies

15

16

A lock-based STM : TL2[Dice et al. DISC 2006]

• Each data item is associated with a version number– TL2 relies on a global versioning clock

• Transaction keeps– Read set: data items & values read– Write set: data items & values to be written

• Deferred update– Changes installed at commit

• Lazy conflict detection– Conflicts detected at commit

100

1717

Read-Only Transactions

12

32

56

19

17

100

Shared Version Clock

Private Read Version (RV)

Copy version clock to local read version clock

RV

Copy version clock to local read version clock

RV

Mem Locks

100

1818

Mem Locks

12

32

56

19

17

100

Shared Version Clock

Private Read Version (RV)

18

Copy version clock to local read version clockCopy version clock to

local read version clockEach read operation is

post-validated checking the lock and version # of

the corresponding memory location

Each read operation is post-validated checking

the lock and version # of the corresponding memory location

Read-Only Transactions

1919

12

32

56

19

17 Private Read Version (RV)

Copy version clock to local read version clockCopy version clock to

local read version clockRead lock, version #, and memory, check

version # less than read clock

Read lock, version #, and memory, check

version # less than read clock

COMMIT if no post-validation fails. Otherwise ABORT as

soon as one Read fails

COMMIT if no post-validation fails. Otherwise ABORT as

soon as one Read fails

100

Shared Version Clock

100

19

Mem Locks

Read-Only Transactions

2020

Read-Only Transactions

12

32

56

19

17

100

Shared Version Clock

Private Read Version (RV)

100

We have taken a snapshot without keeping an explicit read

set!

We have taken a snapshot without keeping an explicit read

set!

20

Mem Locks

Example Execution: Read Only Trans

1. RV Shared Version Clock2. On Read: read lock, read mem,

read lock: check unlocked, unchanged, and v# <= RV

3. Commit.

87 0 87 0

34 0

88 0

V# 0

44 0

V# 0

34 0

99 0 99 0

50 0 50 0

Mem Locks

Reads form a snapshot of memory.No read set!

100 Shared Version Clock

87 0

34 0

99 0

50 0

87 0

34 0

88 0

V# 0

44 0

V# 0

99 0

50 0

100 RV

100

2222

Writing TransactionsMem

Locks

12

32

56

19

17

100

Shared Version Clock

Private Read Version (RV)

Copy version clock to local read version clock

RV

Copy version clock to local read version clock

RV

22

100

2323

Writing TransactionsMem

Locks

12

32

56

19

17

100

Shared Version Clock

Private Read Version (RV)

Copy version clock to local read version clockCopy version clock to

local read version clockOn read/write, check:

Unlocked & version # < RV

Add to R/W set

On read/write, check:Unlocked & version # <

RVAdd to R/W set

23

2424

On CommitMem

Locks

100

Shared Version Clock

100

12

32

56

19

17 Private Read Version (RV)

Acquire write locksAcquire write locks

Art of Multiprocessor Programming

2525

On CommitMem

Locks

100

Shared Version Clock

100101

12

32

56

19

17 Private Read Version (RV)

Acquire write locksAcquire write locks

Increment Version ClockIncrement Version Clock

25

Art of Multiprocessor Programming

2626

On Commit

Mem Locks

100

Shared Version Clock

100101

12

32

56

19

17 Private Read Version (RV)

Acquire write locksAcquire write locks

Increment Version ClockIncrement Version ClockCheck version numbers

≤ RVCheck version numbers

≤ RV

26

2727

On Commit

Mem Locks

100

Shared Version Clock

100101

12

32

56

19

17 Private Read Version (RV)

Acquire write locksAcquire write locks

Increment Version ClockIncrement Version ClockCheck version numbers

≤ RVCheck version numbers

≤ RVUpdate memoryUpdate memoryx

y

27

2828

On CommitMem Locks

100

Shared Version Clock

100101

12

32

56

19

17 Private Read Version (RV)

Acquire write locksAcquire write locks

Increment Version ClockIncrement Version ClockCheck version numbers

≤ RVCheck version numbers

≤ RVUpdate memoryUpdate memory

Update write version #sUpdate write version #s

x

y

101

101

28

Example: Writing Transaction

1. RV Shared Version Clock2. On Read/Write: check

unlocked and v# <= RV then add to Read/Write-Set

3. Acquire Locks4. WV = F&I(VClock)5. Validate each v# <= RV6. Release locks with v# WV

100 Shared Version Clock

87 0 87 0

34 0

88 0

44 0

V# 0

34 0

99 0 99 0

50 0 50 0

Mem Locks

87 0

34 0

99 0

50 0

34 1

99 1

87 0

X

Y

Commit

121 0

121 0

50 0

87 0

121 0

88 0

V# 0

44 0

V# 0

121 0

50 0

100 RV

100120121

X

Y

29

30

A lock-free STM : Dynamic Software Transactional Memory

• Proposed in [Herlihy et al. DISC 2003] – Opacity & obstruction freedom

• Transaction keeps– Read set: data items & values read

• Direct update– Changes installed when the corresponding Write

is executed• Eager conflict detection

– Conflicts detected at encountering time

DSTM : transaction and transactional object representation

• A transaction has – a status field that is initialized to be ACTIVE, and it is later COMMITED or

ABORTED using a CAS primitive– a readlist to store the data items read together with the values read

• Each transactional object has the following structure

start

TMObject

transaction

new object

old object

status

Data

Data

Locator

Status of the transaction that most recently accessed the

object to write it

Current object version

• The current object version is determined by the status of the transaction that most recently accessed the object to WRITE :– committed: the new object is the current– aborted: the old object is the current– active: the old object is the current, and the new is

tentative

• The actual version only changes when a commit is successful

start

o

transactionnew object

old object

committed

Data

DataB’s Locator

1 A creates a new Locator

transactionnew object

old object

A’s Locator

2 A copies the previous new object, and sets new

Data

copy

3 A sets old object to the previous new

active4 Use CAS in

order to replace locator

If CAS fails, A restarts from the

beginning

Write operation : example• Transaction A tries to write object o. Let B be the transaction that

most recently accessed o to WRITE it

Which is the current version of the object if B is active?

• A and B are conflicting transactions, that run at the same time

• Use Contention Manager to decide which should continue and which should abort

• If B needs to abort, try to change its status to aborted (using CAS)

Read operation

• To read object o by a transaction A – Fetch the current version v just as before– Add the pair (o, v) to the read set of A

Validating a transaction

• Before returning the value either read or written, check consistency

• For each pair (o,v) in the read set, verify that v is still the most recently committed version of the transactional object o.

• Check that the status of the transaction is still ACTIVE

Committing a transaction

• The commit needs to do the following:1. Validate the transaction

2. Change the transaction’s status from active to committed (using CAS)

That’s it?

You are here

Irrevocable transactions

Multiversioning

Nested transactions

Distributed STM

Lower bounds

Privatization

Elastic Txs

More references and credits

Many of these slides are (largely inspired) from– The slides of “The Art of Multiprocessor

Programming” by Maurice Herlihy and Nir Shavit– A PODC 2010 talk by Hagit Attiya– Teaching slides by Danny Hendler

Other reference :– Transactional Memory,Foundations, Algorithms,

Tools, and Applications. COST Action Euro-TM IC1001. Lecture Notes in Computer Science, Springer 2014.