1 / 62

Transactions are back But are they the same R. Guerraoui , EPFL

fred
Download Presentation

Transactions are back But are they the same R. Guerraoui , EPFL

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

    8. Double-ended queue

    12. accessing object 1; accessing object 2;

    14. Eswaran et al (CACM’76) Database Papadimitriou (JACM’79) Theory Liskov/Sheifler (TOPLAS’82) Language Knight (ICFP’86) Architecture Herlihy/Moss (ISCA’93) Hardware Shavit/Touitou (PODC’95) Software

    15. Simple example (consistency invariant)

    16. T: x := x+1 ; y:= y+1

    20.

    23. Simple algorithm (DSTM) To write an object O, a transaction acquires O and aborts “the” transaction that owns O To read an object, a transaction T takes a snapshot to see if the system hasn’t changed since T’s last reads; else T is aborted

    24. Simple algorithm (DSTM) Killer write (ownership) Careful read (validation)

    25. More efficient algorithm Apologizing versus asking permission Killer write Optimistic read: validity check at commit time

    27. Back to the example

    28. Division by zero T1: x := x+1 ; y:= y+1

    29. T1: x := 3; y:= 6 Infinite loop

    31.

    32.

    33.

    34. Simple algorithm (DSTM) Careful read (validation) Killer write (ownership)

    35. Visible vs Invisible Read (SXM; RSTM) Write is mega killer: to write an object, a transaction aborts any live one which has read or written the object Visible but not so careful read: when a transaction reads an object, it says so

    36.

    37. Giving up Progress (TL2) To write an object, a transaction acquires it and writes its timestamp To read an object, the transaction aborts itself if the object was written by a transaction with a higher timestamp

    38.

    41. Many more issues Progress? Real-time? Performance? Hardware support? Linguistic support?

    42. Progress

    44. If a transaction T wants to write an object O owned by another transaction, it calls a contention manager Various contention management strategies are possible

    45. System Perspective Scherer and Scott [CSJP 04] Exponential backoff “Karma” Transaction with most work accomplished wins Various priority inheritance schemes … Some work well, but … Can’t prove anything!

    46. Greedy Contention Manager (GHP’05) State Priority (based on start time) Waiting flag (set while waiting) Wait if other has Higher priority AND not waiting Abort other if lower priority OR waiting

    47. Preliminary Result Compare time to complete transaction schedule for Ideal off-line scheduler Knows transactions, conflicts, and start times in advance Greedy contention manager Does not know anything …

    48. Competitive Ratio Let s be the number of objects accessed by all transactions Compare time to commit all transactions Greedy is O(s)-competitive with the off-line adversary GHP’05 O(s2) AEST’06 O(s)

    49. Many more issues Progress? Real-time? Performance? Hardware support? Linguistic support?

    50. Performance How to evaluate transactional memory implementations? So far, mainly micro-benchmarks (linked lists, red-black trees)

    51. Benchmarks STMBench7 (GKV’06)

    52. http://www.cs.wisc.edu/trans-memory/biblio/index.html Sun, Intel, IBM, EU (VELOX) ISCA, OOPSLA, PODC, DISC, POPL, PPoPP, Transact What about SRDS? The Topic is VERY HOT

    53. Transactions are conquering the parallel programming world

    55.

    56.

    58. Real-time T1: y := x; commit T2: x := x+1; commit T3: y := y+1; commit

    61. Classical database transactions

    62. In-memory transactions

    63. Shared memory transactions

More Related