1. Ranjeet Kumar K. Vidyasankar Memorial University St. John’s CANADA
HParSTM: A Hierarchy-based STM Protocol for Supporting Nested Parallelism
Ranjeet Kumar
K. Vidyasankar
Memorial University
St. John’s
CANADA

2. 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

3. 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

4. Our Protocol Nested transactions Closed 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] optimistic protocol for non-nested transactions to closed nested transactions.
TRANSACT 2011

5. 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 of objects.
We consider validation phase and write phase executed together, atomically.
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.
TRANSACT 2011

6. Optimistic approach-Illustration
Validation of t1 fails since x value has been overwritten.
t1 comes up for
validation
t1 starts
r1(x)
t2 validates &
writes w2(x), w2(y)
r1(y)
TRANSACT 2011

7. Optimistic approach-Illustration (STM)
Validation of t1 fails since x value has been overwritten.
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.
t1 comes up for
validation
t1 starts
r1(x)
t2 validates &
writes w2(x), w2(y)
r1(y)
TRANSACT 2011

8. Optimistic approach-Imbs & Raynal’s protocol
We make the reads visible.
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
TRANSACT 2011

9. 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-only or t is not in ow.
TRANSACT 2011

10. 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

11. 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

12. 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.
TRANSACT 2011

13. Compatibility
t1211 and hence t121 should occur before the writes of t12.
t1212 and hence t121 should occur after the writes of t12.
t1211 and t1212 are incompatible.
TRANSACT 2011

14. Compatibility Incompatible sibling transactions are kept track
If one commits, then the other, incompatible, transactions are not allowed to commit.
TRANSACT 2011

15. Correctness
The schedule resulting from pruning all aborted sub-transactions and their descendants is strictly serializable.
For each aborted sub-transaction t, the schedule obtained 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

16. Conclusion
TRANSACT 2011

17. Thank you