software transaction memory for dynamic-sized data structures presented by: mark schall
Post on 21-Dec-2015
221 views
TRANSCRIPT
![Page 1: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/1.jpg)
Software Transaction Memory for Dynamic-Sized
Data Structures
presented by: Mark Schall
![Page 2: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/2.jpg)
The Problem
Using locks introduces well-known problems
Coarse-grained locks: May block threads when not necessary
Fine-grained locks: Complex/Error-prone
![Page 3: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/3.jpg)
Dynamic Software Transactional Memory
Synchronize shared data without using locks
Transaction and transaction objects can be created dynamically
Well suited to implement dynamic-sized data structures: Lists and Trees
![Page 4: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/4.jpg)
Transactions
A sequence of instructions from a single thread Either commits or aborts Appears to take effect one after another
![Page 5: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/5.jpg)
Transaction Object: TMObject
Accessed by transactions
Container for a regular Java object
Transactions can open and read or write to the object
![Page 6: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/6.jpg)
TMObject contd.
Objects encapsulated must implement TMCloneable interface Requires the object to implement a clone() function
DSTM guarantees during cloning the object will not change
![Page 7: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/7.jpg)
TMObject::open()
Transactions access the encapsulated object by calling the open() method
The thread passes the mode in which to open the object with: WRITE or READ
open() throws a Denied exception if the object attempted to open was opened by another thread in a conflicting mode.
![Page 8: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/8.jpg)
IntSet Example
![Page 9: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/9.jpg)
Obstruction-Freedom
Simplifies the implementation
Ensures that halted threads cannot prevent other threads from making progress
Does not rule out livelock: Concurrent threads may repeatedly prevent one another from making progress
Transactions are able to abort other transactions Allows for prioritizing transactions
![Page 10: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/10.jpg)
IntSet Example contd.
Opening objects not necessary to write in read-only mode may reduce conflicts
Releasing the object will relieve any conflicts other transactions may have with that object
Note: Only can release READ objects
![Page 11: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/11.jpg)
Implementation: Opening TMObjects Each transactional object
has three fields:
Transaction: points to the transaction that created the object
oldObject: points to the original version of the object
newObject: points to the copy/modified version of the object
![Page 12: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/12.jpg)
Conflicting TMObjects::open()
If transaction A tries to open an object already opened by another transaction B
A can abort B orA can wait for B to be aborted or commited
This is determined by the contention manager
![Page 13: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/13.jpg)
Read-only TMObjects::open()
Conflicts with open will be resolved using the contention manager
When opened, the object and the last committed version are stored in a local read-only table
Every read-only open in a transaction will increment a counter in the table to match open(READ) and release() calls
![Page 14: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/14.jpg)
Validating
DSTM must validate an open to ensure the state of the transaction
Validation requires two steps:
1) For each pair of TMObject and encapsulated object in the read only table, verify that the object is still the most recent committed object for the transactional object.
2) Check that the Transaction is still active
![Page 15: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/15.jpg)
Committing
Committing requires validating the entries and changing the status of the transaction to COMMITTED
![Page 16: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/16.jpg)
Contention Manager
Each thread/transaction has a contention manager
Determines whether a transaction should either: abort another transaction immediately allow the other transaction a chance to complete
Explicit measures are often necessary to avoid starvation
Its responsibility is progress
Contention managers may consult with each other
![Page 17: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/17.jpg)
Contention Manager Interface
Notification methods: informs the manager of relevant events
Success/Failure of commits Attempts to open objects
Feedback methods: determine the actions that should be taken in circumstances
Aborting another transaction
![Page 18: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/18.jpg)
Contention Manager
Correctness (Informally): "Any active transaction that asks sufficiently many times must eventually get permission to abort a conflicting transaction"
Preserves obstruction freedom
Correctness does not guarantee progress
![Page 19: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/19.jpg)
Contention Manager contd.
Application, environment, and other factors decide policy
Modular implementation allows fine tuning of desired: progress guarantees transaction prioritization
![Page 20: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/20.jpg)
Content Management Examples
Aggressive: Always and immediately grants permission to abort other transactions
Polite: Adaptively backs off a few times when encountering conflicts Sleeps for a random amount of time Any other attempts will double the amount of time At some threshold the manager will allow an abort
![Page 21: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/21.jpg)
Experiments
Measure the number of operations completed (committed) over a period of 20 seconds
Number of threads varied from 1 and 576 threads
Each operation chose randomly to delete or insert a value from 0 to 255
![Page 22: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/22.jpg)
Results
![Page 23: Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall](https://reader035.vdocuments.site/reader035/viewer/2022070323/56649d6c5503460f94a4c436/html5/thumbnails/23.jpg)
Conclusions
Contention management schemes are required to avoid livelock
Implementation still requires forethought from programmers