Presentation is loading. Please wait.

Presentation is loading. Please wait.

A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott.

Similar presentations


Presentation on theme: "A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott."— Presentation transcript:

1 A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott

2 Software Transactional Memory Introduction

3 ● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization

4 Introduction ● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization ● implemented a transactional memory by extending multiprocessor cache coherency protocols ● provided an instruction set for accessing shared memory

5 Introduction ● We will see ● Software Transactional Memory (Shavit 95) ● Hash Table Based STM (Harris 03) ● Dynamic Software Transactional Memory (DSTM) ● a Lock Free Object Based STM (FSTM) [Fraser 03] ● We will make a qualitative comparison of these implementations

6 STM, by Shavit and Toitou[1995] The STM Algorithm

7 STM, by Shavit and Toitou[1995] ● The Transaction lists the memory it needs ● The Transaction attempts to take “ownership” of the needed memory ● If any ownerships cannot be taken, the transaction fails and retries ● Change the state to COMITTED atomically ● Make updates ● Release all ownerships

8 STM, by Shavit and Toitou[1995] ● A memory word is used as the concurrent object ● Each memory word has a corresponding ownership Record (orec) ● The orec may be NULL (no transaction owns the orec) ● The orec may be a reference to a transaction record

9 STM, by Shavit and Toitou[1995] MemoryOwnership Records Null Transaction Record

10 STM, by Shavit and Toitou[1995] ● Helping – used to avoid livelocks – Ownerships are acquired in some global order – if A finds that process B owns a record, A will make B's updates on B's behalf. – helping is done non-recursively

11 STM, by Shavit and Toitou[1995] ● Drawbacks – To ensure ordered access, one must know all memory words one will access before one starts – each shared memory word requires an orec of equal size. This doubles the memory requirement of STM – There is an efficiency drawback, due to contention overhead during helping.

12 Hash Table Based STM ● Word based STM ● Uses a hash table for the orecs ● provides an interface to the STM

13 Hash Table Based STM ● Data Structures – The Application Heap – The Hash Table of orecs – transaction descriptors

14 Hash Table Based STM ● Application Heap is the shared memory that holds the data the concurrent processes use ● Uses a hash table for the orecs – The shared memory locations hash into the orecs hash table. – Each orec has a version number or a reference to the transaction descriptor of the transaction that currently owns the orec – When a transaction owns an orec it also owns all other memory hashing into that orec!

15 Transaction Descriptor Ownership Record Application Heap

16 Hash Table Based STM ● The Interface – void STMStart() – stm_word STMRead( addr a ) – void STMWrite( addr am stm_word w ) – void STMAbort() – boolean STMCommit() – boolean STMValidate() – void STMWait()

17 Transaction Descriptor Ownership Record Application Heap Before

18 Transaction Descriptor Ownership Record Application Heap STMRead or STMWrite New Transaction Entry : The Address being accessed Old Value and Version num. New Value and Version num

19 Transaction Descriptor Ownership Record Application Heap STMCommit Address being accessed Old Value and Version num. New Value and Version num

20 Transaction Descriptor Ownership Record Application Heap Read Conflict ! Address being accessed Old Value and Version num. New Value and Version num transaction 2

21 Transaction Descriptor Ownership Record Application Heap Acquire Conflict ! Address being accessed Old Value and Version num. New Value and Version num transaction 2

22 Hash Table Based STM ● Acquire Conflict : – If the conflicting transaction is ACTIVE the current transaction aborts it. – Then the current transaction verifies the consistency of the version number of the orec under conflict with the latest valid version number in the conflicting transaction's descriptor. If an inconsistency is detected, Abort and release all acquired ownerships – next help or steal

23 Hash Table Based STM ● Stealing vs Helping – Helping is expensive due to contention – To Steal, the transaction merges the transaction entries corresponding to the orec under conflict into its own transaction descriptor using atomic CAS.

24 Hash Table Based STM ● Design and Efficiency Issues – Contention management, or polite vs aggressive : polite algorithms perform better – Bounded Memory Blow-Up Problem : When a stealer merges descriptors, the stealer may end up possessing several records it doesn't care about

25 Hash Table Based STM ● An LL/SC based approach may reduce the effects of the Bounded Memory Blow-Up problem.

26 Object-based Software Transactional Memory Systems

27 Dynamic Software Transaction Memory (DSTM)

28 DSTM ● a Transactional Memory object is a wrapper around the concurrent data object. This contains a pointer to ● a Locator object stores a pointer to a descriptor of the most recent modifying transaction, and to the old and new versions of the data object.

29 TM Obj. Transaction New Obj Old Obj Transaction New Obj Old Obj Committed Transaction Shared Obj. New Ver. Shared Obj, Old Ver. New Active Transaction Shared Obj, new Vers.Copy

30 DSTM ● A Transaction Descriptor may be in one of 3 states. These determine the most recent valid version of the data object – ACTIVE: the old version is correct – ABORTED: the old version is correct – COMMITTED : the new version is correct

31 DSTM ● The locator is not an orec – The locator is referenced by the TM object, the orec is found by a hash function – The locator points to old and new versions of the data, the orec stores a version number or points to a descriptor with the old and new versions of the data – The locator does not require a version number

32 Object-based Software Transactional Memory Systems Lock-Free Object Based STM (FSTM)

33 Lock-Free Object Based STM (FSTM) ● Data Structures – Object Header wraps the concurrent object – Transaction Descriptor is used by each transaction to maintain the list of in-use concurrent objects. This object maintains two lists (read only and read write) – Object Handles consist of references to an object header, the concurrent object referenced bu the object header and a shadow copy of the concurrent object.

34 UNDECIDED Object Ref, old and new data, next handle List of object handles Object HeaderConcurrent Obj.Shadow Copy

35 Lock-Free Object Based STM (FSTM) ● To access an object – Open the object using that object header – This creates an object handle in that object's descriptor

36 Lock-Free Object Based STM (FSTM) ● Committing a change – Acquire phase – Decision Point – Release Phase

37 Lock-Free Object Based STM (FSTM) ● Acquire Phase – Acquire each concurrent object in read-write object handle list. Do so in global total order using atomic CAS – on fail, if the conflict is with a modified object, abort – on fail, if conflict is with an uncommitted transaction, help the conflicting transaction – decide whether to commit or abort

38 Lock-Free Object Based STM (FSTM) ● READ-CHECKING state – Decide whether the transactions committed or aborted – Begin the read phase, and walk through the descriptor's read-only list – If there is a conflict, verify the data's consistency – if the conflict is with an UNDECIDED transaction, verify the old data in the conflicting object handle. If the data object is different, ABORT

39 The Qualitative Comparison ● Object Acquire Semantics ● Indirection Overhead ● Space Usage ● Search Overhead ● Contention Management vs Helping ● Transaction Validation

40 The Qualitative Comparison ● Object Acquire Semantics – Eager Acquire vs Lazy Acquire

41 The Qualitative Comparison ● Indirection Overhead – DSTM requires n+1 CAS to commit – FSTM and Hash Table require 2N+2 CAS

42 The Qualitative Comparison ● Space Usage – The space requirement of DSTM is more than twice that of FSTM usually

43 The Qualitative Comparison ● Search Overhead – FSTM and Hash Table require a search for the concurrent object under conflict – DSTM does not

44 The Qualitative Comparison ● Contention Management vs Helping – need empirical testing of this

45 The Qualitative Comparison ● Transaction Validation

46 Finis


Download ppt "A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott."

Similar presentations


Ads by Google