The document summarizes Software Transactional Memory (STM) and the Multiverse framework. STM provides an alternative to classic locking-based concurrency control using transactions on memory. Multiverse is an STM framework for Java that uses transactions to provide atomic, isolated and consistent access to shared memory without exposing locking details. It supports various programming models including POJO and managed reference based approaches.

1. Multiverse: STM Peter Veentjer Founder of Multiverse Software Transactional Memory http://multiverse.googlecode.com

2. Who am I Java Developer currently working for Qiy.

3. 8 Years Professional Experience

4. Projects I worked on (and I'm proud of) Expert systems / Prolog compiler/interpreters

5. Batch processing systems

6. Enterprisy backend systems Main intererrests Concurrency control (Java, Database, STM)

7. Distributed computing

8. Software architecture

9. Patterns

10. Don't wait with your questions! We still know the context

11. There is enough time

12. I like the discussion

13. Agenda What is wrong with classic concurrency control?

14. Software Transactional Memory (Multiverse) as alternative concurrency control implementation

15. What is wrong? Operations not composable

16. public class Account{ private int balance; public synchronized int getBalance(){ Return balance; } public synchronized void setBalance(int newBalance){ this.balance = newBalance; } public inc(int delta){ setBalance(getBalance()+delta); } } Not Composable

17. What is wrong? Operations not composable

18. Expose Implementation details

19. public class Account{ private int balance; public synchronized int getBalance(){ Return balance; } public synchronized inc(int delta){ this.balance += balance; } } static void transfer(Account from, Account to, int amount){ synchronized(from){ synchronized(to){ from.inc(-amount); to.inc(amount); } } } Expose implementation details

20. public class Account{ private int balance; private Lock lock = new ReentrantLock(); public int getBalance(){ ... } public inc(int delta){ lock.acquire() try{ balance+=delta; }finally{ lock.release() } } } void transfer(Account from, Account to, int amount{ synchronized(from){ synchronized(to){ from.inc(-amount); to.inc(amount); } } } Expose implementation details

21. What is wrong? Operations not composable

22. Expose Implementation details

23. Deadlock prone

24. static void transfer(Account from, Account to, int amount){ synchronized(from){ synchronized(to){ from.inc(-amount); to.inc(amount); } } } Deadlocks

25. What is wrong? Operations not composable

26. Expose Implementation details

27. Deadlock prone

28. Operation is not atomic

29. public class Account{ private int balance; public int getBalance(){ Return balance; } public inc(int delta){ if(balance + delta<0) Throw new NotEnoughCashException() this.balance += balance; } } static void transfer(Account from, Account to, int amount){ to.inc(amount); from.inc(-amount); } Not atomic

30. Questions? It this the right way to deal with the increasing number of cores?

31. Could concurrency control be just as easy as gc?

32. STM: What? Concurrency control through database like transactions on (Java) Memory (failure) Atomicity

33. Consistency (task of the Java Objects)

34. Isolation

35. Durability (not provided)

36. Multiverse: What? STM Framework for the JVM Main engine is Alpha STM Engine: TL2 Based Working on it for more than 1 year

37. Multiple Programming Models POJO based icw Annotations Object granularity

38. Instrumentation (very time consuming!!)

39. @AtomicObject public class Account{ private int balance; public int getBalance(){ Return balance; } public void inc(int delta){ this.balance += balance; } } @AtomicMethod static void transfer(Account from, Account to, int amount){ from.inc(-amount); to.inc(amount); } Using STM: POJO based

40. @AtomicObject public class Account{ private int balance; @Exclude private int ignore; public int getBalance(){ Return balance; } public void inc(int delta){ this.balance += balance; } } Excluding fields

41. Multiverse: What? STM Framework for the JVM Main engine is Alpha STM Engine: TL2 Based Working on it for more than 1 year

42. Multiple Programming Models POJO based icw Annotations Object granularity

43. Instrumentation (very time consuming!!) Managed reference based Field granularity

44. @AtomicObject public class Account{ final Ref<Integer> balance = new Ref<Integer>(); public int getBalance(){ Return balance.get(); } public void inc(int delta){ balance.set(balance.get()+delta); } } @AtomicMethod static void transfer(Account from, Account to, int amount){ from.inc(-amount); to.inc(amount); } Using STM : Managed Ref based

45. Multiverse: What? STM Framework for the JVM Main engine is Alpha STM Engine: TL2 Based Working on it for more than 1 year

46. Multiple Programming Models POJO based icw Annotations Object granularity

47. Instrumentation (very time consuming!!) Managed reference based Field granularity Akka Project of Jonas Boner

48. Multiverse: How? Seperate State from Object identity Atomic Object (Object identity)

49. Tranlocal (State)

50. @AtomicObject public class Account{ private int balance; public int getBalance(){ Return balance; } public inc(int delta){ this.balance += balance; } } Multiverse: How

51. @AtomicObject public class Account implements AtomicObject{ AtomicReference<Account__Tranlocal> current = New AtomicReference(); public int getBalance(){ Account__Tranlocal a = getTransaction().load(this); return a.balance; } public void inc(int delta){ Account__Tranlocal a = getTransaction().load(this); a.balance+=delta; } public Account__Tranlocal load(long version){..} public boolean lock(Transaction t){..} public void store(Account__Tranlocal tranlocal){...} ... } public class Account__Tranlocal{ long version; Account atomicObject; int balance; } Multiverse: How

52. Multiverse: Failure Atomicity Since all changes are made on the tranlocals, just drop the transaction

53. Drop in collections Drop in collections BlockingQueue & Queue

54. BlockingDeque & Deque

55. LinkedList

56. Planned TreeMap/TreeSet

57. HashMap/HashSet

58. ArrayList

59. import java.util.*; final List<String> l = Collections.synchronizedList(new LinkedList()); void add(String item){ l.add(item); } void addAll(String... items){ for(String item:items){ l.add(item); } } Drop in collections - before

60. import java.util.*; import org.multiverse.datastructures.collections.*; final List<String> l = new StrictLinkedBlockingDeque(); void l(String item){ l.add(item); } @AtomicMethod void addAll(String... items){ for(String item:items){ l.add(item); } } Drop in collections - after

61. import java.util.*; import org.multiverse.datastructures.collections.*; final List<String> l1 = new StrictLinkedBlockingDeque(); final List<String> l2 = new StrictLinkedBlockingDeque(); @AtomicMethod void add(String item){ l1.add(item); l2.add(item); } @AtomicMethod void addAll(String... items){ for(String s: items){ add(s); } } Drop in collections – Woohaa

62. Readonly vs Update Transactions Update Transaction Tracks Reads (called readset)

63. Tracks Writes (called writeset)

64. Expensive to use

65. Expensive to commit Readonly Transaction Doesn't track reads/writes

66. Very cheap to use

67. No commit needed

68. @AtomicObject public class IntRef{ private int value; public void set(int newValue){ this.newValue = newValue; } @AtomicMethod(readonly = true) public int get(){ return value; } } Readonly vs Update Transactions

69. Transactions can fail Transaction can fail Load conflicts Version doesn't exist anymore

70. Load ambiguity

71. ... Commit conflicts Write conflicts

72. Locks can't be obtained

73. ... Transactions are retried automatically!

74. @AtomicObject Class IntRef{ int value = 0; @AtomicMethod(retryCount = 100) void inc(){ value++; } } Automatic retrying transactions

75. @AtomicObject Class IntRef{ int value = 0; void inc(){ Transaction t = getTransaction() if(t!=null){ //there already is a transaction value++; }else{ //there is no transaction, lets create one t = stm.startTransaction() int attempt = 1; while(attempt-1 <= 100){ try{ value++; t.commit() }catch(RecoverableException ex){ attempt++; t.abortAndReset(); } } throw new TooManyRetriesException(); } } } Automatic retrying transactions

76. Automatic retrying transactions Some ramblings Be careful with non transactional resources IO

77. Non transactional objects Backoff policies No backoff policy

78. Exponential backoff policy

79. Priority based backoff policy

80. STM: Notification retry

81. @AtomicObject public class TStack<E>{ private Node<E> head; public void push(E item){ head = new Node<E>(head, item); } public E pop(){ if(head == null){ retry(); } Node<E> oldHead = head; head = head.next; return oldHead.value; } static class Node{ final Node<E> next; final E value; Node(Node<E> next, E value){ this.next = next; this.value = value; } } }

82. STM: Notification retry multiple sources

83. TStack<Integer> stack1 = new TStack<Integer>(); TStack<Integer> stack2 = new TStack<Integer>(); @AtomicMethod public int popFromOneOfTheStacks(){ if(!stack1.isEmpty()){ Return stack1.pop(); } if(!stack2.isEmpty()){ Return stack2.pop(); } retry(); return -1;//is never executed }

84. STM: Notification retry multiple sources orelse

85. TStack<Integer> stack1 = new TStack<Integer>(); TStack<Integer> stack2 = new TStack<Integer>(); @AtomicMethod public int popFromOneOfTheStacks(){ return new OrElseTemplate<Integer>(){ void runOr(){ return stack1.pop(); } void runElse(){ return stack2.pop(); } }.execute(); }

86. TStack<Integer> stack1 = new TStack<Integer>(); TStack<Integer> stack2 = new TStack<Integer>(); @AtomicMethod public int popFromOneOfTheStacks(){ return new OrElseTemplate<Integer>(){ void runOr(){ return stack1.pop(); } void runElse(){ return stack2.pop(); } }.execute(); }

87. atomic{ either{ stack1.pop() }orelse{ stack2.pop() } }

88. STM: Notification retry multiple sources orelse

89. planned bounded waits Method scope

90. Transaction scope Interruptable waits

91. STM: Isolation State (Tranlocal) is not shared during execution So no dirty reads possible Transaction level read consistency based on version Repeatable reads

92. No phantom reads Oracle 'serialized' isolation level out of the box Real serialized isolation planned

93. STM : Synchronization Encounter time locking

94. Commit time locking Optimistic (based on the version)

95. Higher concurrency Readers don't block writers

96. Writers don't block readers Increased chance of transaction failure Planned Optional pessimistic locking (select .. for update)

97. Java Memory Model STM Framework for the JVM Main engine is Alpha STM Engine: TL2 Based Working on it for more than 1 year

98. Multiple Programming Models POJO based icw Annotations Object granularity

99. Instrumentation (very time consuming!!)

100. Scalability There is no shared state so it should scale linear Except!! the global clock (e.g. atomicLong) Strict Clock

101. Relaxed Clock Solutions Use multiple STM instances Objects can't be shared between STM instances! Remove the global clock Distributed version

102. Multiverse: Plans 1 Performance optimizations

103. More collection classes

104. Scala Integration

105. Profiler (sampling & event)

106. (Persistent?) version history

107. Improve Instrumentation

108. Fairness/Starvation

109. Remove the global clock

110. Distributed

111. Striping

112. Multiverse: Plans 2 JMS implementation

113. JTA implementation

114. JPA implementation

115. Q & A [email_address]