1 / 23

Software Transaction Memory for Dynamic-Sized Data Structures

Software Transaction Memory for Dynamic-Sized Data Structures. presented by: Mark Schall. The Problem. Using locks introduces well-known problems Coarse-grained locks:     May block threads when not necessary Fine-grained locks:     Complex/Error-prone.

reynaldosimpson
Télécharger la présentation

Software Transaction Memory for Dynamic-Sized Data Structures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall

  2. The Problem Using locks introduces well-known problems Coarse-grained locks:     May block threads when not necessary Fine-grained locks:     Complex/Error-prone

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

  4. Transactions A sequence of instructions from a single thread Either commits or aborts Appears to take effect one after another

  5. Transaction Object: TMObject Accessed by transactions Container for a regular Java object Transactions can open and read or write to the object

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

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

  8. IntSet Example

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

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

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

  12. Conflicting TMObjects::open() If transaction A tries to open an object already opened by another transaction B A can abort B or A can wait for B to be aborted or commited This is determined by the contention manager

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

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

  15. Committing Committing requires validating the entries and changing the status of the transaction to COMMITTED

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

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

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

  19. Contention Manager contd. Application, environment, and other factors decide policy Modular implementation allows fine tuning of desired:     progress guarantees      transaction prioritization

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

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

  22. Results

  23. Conclusions Contention management schemes are required to avoid livelock Implementation still requires forethought from programmers

More Related