K. Vidyasankar Memorial University St. Johns CANADA Software - - PowerPoint PPT Presentation

HParSTM: A Hierarchy-based STM Protocol for Supporting Nested Parallelism Ranjeet Kumar

• K. Vidyasankar

Memorial University

• St. John’s

CANADA

Software Transactional Memory (STM) Systems

 Processes execute programs.  Atomic regions are specified in the programs.  Atomic regions are treated as transactions.  Transactions are executed concurrently.  Correctness of concurrent executions is to be assured

by STM system.

TRANSACT 2011 2

Correctness Criterion

 Opacity

 Both committed and aborted transactions should read from

a consistent state of the shared memory.

 The state resulting from a (strongly) serializable execution of

some committed transactions is taken to be consistent.

TRANSACT 2011 3

Our Protocol

 Nested transactions

 A (root-level) transaction consists of sub-transactions, which

again may consist of sub-transactions, and so on.

 Closed nested transactions

 Aborted sub-transactions are ignored.  Commitment of sub-transactions are local – at the parent

level.

 Only the writes of the root-level transactions affect the

shared memory state.

 We extend Imbs and Raynal’s [OPODIS 2008]

• ptimistic protocol for non-nested transactions to

closed nested transactions.

TRANSACT 2011 4

Optimistic Approach

 Three phases

 Execution phase – writes are done in local copies of objects.  Validation phase.  Write phase – local copy values are written in global copies

• f objects.

 Validation of a transaction amounts to ensuring that

the values of the objects read by that transaction were not overwritten by other already validated transactions.

 We consider validation phase and write phase

executed together, atomically.

TRANSACT 2011 5

Optimistic approach-Illustration

 Validation of t1 fails since x value has been

• verwritten, and hence t1 should be aborted.

TRANSACT 2011 6

t1 starts r1(x) t2 validates &

writes w2(x), w2(y)

r1(y) t1 comes up for

validation

Optimistic approach-Illustration (STM)

 Validation of t1 fails since x value has been

• verwritten, and hence t1 should be aborted.

 x and y values that t1 read are not from a consistent

state.

 We want aborted transactions also to read from

consistent states

 t1 should be forbidden to read y.

TRANSACT 2011 7

t1 starts r1(x) t2 validates &

writes w2(x), w2(y)

r1(y) t1 comes up for

validation

Optimistic approach-Imbs & Raynal’s protocol

 The reads are made visible. TRANSACT 2011 8

t1 starts r1(x) t2 validates &

writes w2(x), w2(y)

r1(y)

add t1 to x.rs add t1 to ow, x.fbd, y.fbd disallow since t1 is in y.fbd

Optimistic approach- Imbs & Raynal’s protocol

 Reads are visible.  When a read step is forbidden, the transaction is

aborted and treated as a read-only transaction with the read steps already performed.

 Validation of a transaction t succeeds if t is a read-

• nly or t is not in ow.

TRANSACT 2011 9

Our extension

 Imbs and Raynal’s approach is employed at each

level of the nested transaction tree.

 For each sub-transaction t, we have

 Local copies of objects accessed by t  Set ow  Sets x.rs, x.fbd, for each local object x.

TRANSACT 2011 10

Operations of Sub-transaction t

 Read

 If the value is not available locally, then it is obtained from

the nearest ancestor having the value.

 In the worst case, the value from the global copy is read.  To read x from an ancestor t’, we need to ensure that

t’.x.fbd does not include the transactions from t to t’ and their descendants who have merged with them.

 Commit

 The commitment conditions as in Imbs and Raynal’s protocol

are applied at each level.

 In addition, we need to check compatibility.  An aborted transaction’s write steps as well as read steps

are ignored (at the parent’s and other ancestors’ levels).

TRANSACT 2011 11

Nested Parallelism

 For each sub-transaction t,

 We allow t as well as its children to execute concurrently.  If t is aborted, then all the descendants of t are also

aborted.

 t will be committed only after all its children have committed

• r aborted.

TRANSACT 2011 12

Compatibility

 t111 and hence t11 should occur before t12.  t112 and hence t11 should occur after t12. 

t111 and t112 are incompatible.

TRANSACT 2011 13

1 2 3

Compatibility

 Incompatible sibling transactions are kept track of.  If one commits, then the other, incompatible,

transactions are not allowed to commit.

TRANSACT 2011 14

Correctness

 The schedule resulting from pruning all aborted sub-

transactions and their descendants is strictly serializable.

 For each aborted sub-transaction t, the schedule

• btained by pruning all the aborted descendants of t

and including all the committed transactions at the ancestor levels and “closed” versions of the active ancestors is strictly serializable.

TRANSACT 2011 15

Discussion

 Overhead

 Buffers and auxiliary sets (ow, x.rs, x.fbd, etc.) at every

non-leaf node, and updating them;

 Lock management at every level; and  Transfer of data between levels.

 Can sub-transactions be executed independently?

 Needed data can be sent as parameters?  Other data can be read directly from global values?

 Mixing both will not work in certain cases.

 Types of workload

 Flexible parallelism – limiting concurrent executions of child

and parent, of different children, etc.?

TRANSACT 2011 16

Thank you