The document introduces 'dl-check,' a dynamic potential deadlock detection tool for Java programs that addresses issues such as data races and resource deadlocks. It outlines its algorithm, implementation, and evaluation, focusing on concepts like lock acquisition order, potential deadlocks, and the lock-order graph. The tool aims to provide efficient deadlock detection by capturing execution traces and minimizing false positives through dynamic analysis.

1. Dl-Check: dynamic potential deadlock
detection tool for Java programs
Nikita Koval1,2 Dmitry Tsitelov2 Roman Elizarov2
1ITMO University, Computer Technology Department,
St. Petersburg, Russia
koval@rain.ifmo.ru
2Devexperts, LLC, St. Petersburg, Russia,
dxlab@devexperts.com
TMPA Conference, March 2017

2. Table of contents
1. Introduction
2. Algorithm
3. Implementation
4. Evaluation
5. Conclusion
Slide 2/65. Copyright © 2017. Devexperts LLC. All rights reserved.

3. INTRODUCTION

4. Multithreaded programming problems
• Data race
• Starvation
• Livelock
• Deadlock
- Communication deadlock
- Resource deadlock
Slide 4/65. Copyright © 2017. Devexperts LLC. All rights reserved.

5. Resource deadlock
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
transfer(a, b, …):
1 a.lock()
4 b.lock()
transfer(b, a, …):
2 b.lock()
3 a.lock()
DEADLOCK!
Slide 5/65. Copyright © 2017. Devexperts LLC. All rights reserved.

6. Analysis approaches
• Static analysis
- Can guarantee deadlock-freedom
- Many false positives
• Model checking
- Can guarantee deadlock-freedom
- Requires a lot of computational resources
• Dynamic analysis
- Depends on the execution
- Produces few false positives
- Applicable for large programs
Slide 6/65. Copyright © 2017. Devexperts LLC. All rights reserved.

7. Dynamic analysis
• Collecting execution traces
- Analyzes collected traces off-line
- e.g. JCarder, MulticoreSDK
• Detecting immediately when a potential deadlock happens
- Has all context information, such as stack traces
- e.g. VisualThreads
Slide 7/65. Copyright © 2017. Devexperts LLC. All rights reserved.

8. ALGORITHM

9. “Acquired before” relation
• Lock 𝒖 is acquired before lock 𝒗 (𝒖 → 𝒗) if at some point
lock 𝒗 is acquired under lock 𝒖 in the same thread
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 c.lock()
4 d.lock()
𝑎 → 𝑏
𝑎 → 𝑐
𝑎 → 𝑑
𝑏 → 𝑐
𝑏 → 𝑑
𝑐 → 𝑑
Slide 9/65. Copyright © 2017. Devexperts LLC. All rights reserved.

10. Lock hierarchy
• Lock hierarchy is a partial order on locks, where
𝑢 → 𝑣 ⇒ 𝑜𝑟𝑑 𝑢 < 𝑜𝑟𝑑 𝑣
𝑜𝑟𝑑 𝑎 < 𝑜𝑟𝑑 𝑏
𝑜𝑟𝑑 𝑎 < 𝑜𝑟𝑑 𝑐
𝑜𝑟𝑑 𝑎 < 𝑜𝑟𝑑 𝑑
𝑜𝑟𝑑 𝑏 < 𝑜𝑟𝑑 𝑐
𝑜𝑟𝑑 𝑏 < 𝑜𝑟𝑑 𝑑
𝑜𝑟𝑑 𝑐 < 𝑜𝑟𝑑(𝑑)
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 c.lock()
4 d.lock()
Slide 10/65. Copyright © 2017. Devexperts LLC. All rights reserved.

11. Potential deadlock
• Lock hierarchy is a primary method to avoid deadlocks
• Potential deadlock is a lock hierarchy violation
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 b.lock()
4 a.lock()
𝑎 → 𝑏
𝑏 → 𝑎
𝑜𝑟𝑑 𝑎 < 𝑜𝑟𝑑 𝑏
𝑜𝑟𝑑 𝑏 < 𝑜𝑟𝑑(𝑎)
Slide 11/65. Copyright © 2017. Devexperts LLC. All rights reserved.

12. Lock-order graph (1)
• Every vertex is associated with a lock
• Edge 𝒖, 𝒗 means that 𝒖 → 𝒗
• Cycles refer to potential deadlocks
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 unlock(a, b)
4 b.lock()
5 a.lock()
6 unlock(a, b)
Slide 12/65. Copyright © 2017. Devexperts LLC. All rights reserved.

13. Lock-order graph (2)
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 unlock(a, b)
4 b.lock()
5 a.lock()
6 unlock(a, b)
• Every vertex is associated with a lock
• Edge 𝒖, 𝒗 means that 𝒖 → 𝒗
• Cycles refer to potential deadlocks
Slide 13/65. Copyright © 2017. Devexperts LLC. All rights reserved.

14. Lock-order graph (3)
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 unlock(a, b)
4 b.lock()
5 a.lock()
6 unlock(a, b)
• Every vertex is associated with a lock
• Edge 𝒖, 𝒗 means that 𝒖 → 𝒗
• Cycles refer to potential deadlocks
Slide 14/65. Copyright © 2017. Devexperts LLC. All rights reserved.

15. Lock-order graph (4)
Thread 1 Thread 2
1 a.lock()
2 b.lock()
3 unlock(a, b)
4 b.lock()
5 a.lock()
6 unlock(a, b)
• Every vertex is associated with a lock
• Edge 𝒖, 𝒗 means that 𝒖 → 𝒗
• Cycles refer to potential deadlocks
Slide 15/65. Copyright © 2017. Devexperts LLC. All rights reserved.

16. Minimization principle: problem
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 16/65. Copyright © 2017. Devexperts LLC. All rights reserved.

17. Minimization principle: problem (1)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 17/65. Copyright © 2017. Devexperts LLC. All rights reserved.

18. Minimization principle: problem (2)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 18/65. Copyright © 2017. Devexperts LLC. All rights reserved.

19. Minimization principle: problem (3)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 19/65. Copyright © 2017. Devexperts LLC. All rights reserved.

20. Minimization principle: problem (4)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 20/65. Copyright © 2017. Devexperts LLC. All rights reserved.

21. Minimization principle: problem (5)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 21/65. Copyright © 2017. Devexperts LLC. All rights reserved.

22. Minimization principle: problem (6)
• Two cycles may refer to the same potential deadlock
Thread 1 Thread 2
1 a.lock()
2 c.lock()
3 b.lock()
4 unlock(a,b,c)
5 b.lock()
6 a.lock()
7 unlock(a,b)
Slide 22/65. Copyright © 2017. Devexperts LLC. All rights reserved.

23. Minimization principle: rule
• The shorter cycle is more useful
• Only one shortest cycle is to be produced
Slide 23/65. Copyright © 2017. Devexperts LLC. All rights reserved.

24. Algorithm layout
• Capture lock acquire and release operations
• After lock acquisition:
- Add lock to the multiset of locks held by the current thread
- Add new edges to the lock-order graph
- Report new cycles
• Before lock release:
- Remove lock from the multiset of held locks
Slide 24/65. Copyright © 2017. Devexperts LLC. All rights reserved.

25. Lock acquisition and release capturing
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Thread #1Thread #2Slide 25/65. Copyright © 2017. Devexperts LLC. All rights reserved.

26. Lock acquisition and release capturing (1)
Thread #1Thread #2
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 26/65. Copyright © 2017. Devexperts LLC. All rights reserved.

27. Lock acquisition and release capturing (2)
Thread #1Thread #2
b
a
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 27/65. Copyright © 2017. Devexperts LLC. All rights reserved.

28. Lock acquisition and release capturing (3)
Thread #1Thread #2
b
a
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 28/65. Copyright © 2017. Devexperts LLC. All rights reserved.

29. Lock acquisition and release capturing (4)
Thread #1Thread #2
b
a
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 29/65. Copyright © 2017. Devexperts LLC. All rights reserved.

30. Lock acquisition and release capturing (5)
Thread #1Thread #2
b
a
c
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 30/65. Copyright © 2017. Devexperts LLC. All rights reserved.

31. Lock acquisition and release capturing (6)
Thread #1Thread #2
a
c
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 31/65. Copyright © 2017. Devexperts LLC. All rights reserved.

32. Lock acquisition and release capturing (7)
Thread #1Thread #2
a
c
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 32/65. Copyright © 2017. Devexperts LLC. All rights reserved.

33. Lock acquisition and release capturing (8)
Thread #1Thread #2
a
c
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 33/65. Copyright © 2017. Devexperts LLC. All rights reserved.

34. Lock acquisition and release capturing (9)
Thread #2Thread #1
c
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 34/65. Copyright © 2017. Devexperts LLC. All rights reserved.

35. Lock acquisition and release capturing (10)
Thread #1Thread #2
b
Thread 1 Thread 2
4 a.lock()
5 c.lock()
7 b.lock()
8 a.unlock()
9 c.unlock()
10 b.unlock()
1 b.lock()
2 a.lock()
3 a.unlock()
6 b.unlock()
Slide 35/65. Copyright © 2017. Devexperts LLC. All rights reserved.

36. Multiset of held locks
• Common lock usage patterns
synchronized(o) {
// Do something
}
synchronized void f() {
// Do something
}
l.lock()
try {
// Do something
} finally {
l.unlock()
}
• Locks are acquired and released in LIFO (stack) order
Slide 36/65. Copyright © 2017. Devexperts LLC. All rights reserved.

37. Multiset of held locks
• Stack with possibility of removing from the middle
• Commonly works in 𝑂 1
• Works in 𝑂(𝐵) at worst
- 𝐵 – number of locks acquired by the current thread
Slide 37/65. Copyright © 2017. Devexperts LLC. All rights reserved.

38. Topological order
• Incremental topological order maintenance
- MNR algorithm suggested by Marchetti-Spaccamela et al.
• The acyclic part of the lock-order graph is to be kept
• Adding (𝑢, 𝑣) leads to topological order violation ⇒ the
shortest path 𝑣 ↝ 𝑢 relates to the cycle
Slide 38/65. Copyright © 2017. Devexperts LLC. All rights reserved.

39. New nodes processing
• Typical pattern in the lock-order graph
x
a
bc
d
e
f g
h
• One long-lived lock at the center and many hundreds of
short-lived locks around it
Slide 39/65. Copyright © 2017. Devexperts LLC. All rights reserved.

40. New nodes processing
• Lock-free buffer for new nodes
• Initialize topological order value
- if buffer is full
- when outgoing edge should be added
New lock nodes buffer
Lock-order graph
Slide 40/65. Copyright © 2017. Devexperts LLC. All rights reserved.

41. Complexity
• On lock acquire
- If acquisition does not produce new cycles
• Typical case
• 𝑂(𝐵 + |𝑉| + |𝐸|)
- New cycle detected
• 𝑂 𝐵 ⋅ 𝑉 + 𝐸
• On lock release
- Removes the lock from the lock multiset
• 𝑂 1 typically
• 𝑂 𝐵 at worst
Slide 41/65. Copyright © 2017. Devexperts LLC. All rights reserved.

42. Limitations: cycle minimization
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(a, c, …)
2 transfer(c, b, …)
3 transfer(b, a, …)
4 transfer(a, b, …)
Slide 42/65. Copyright © 2017. Devexperts LLC. All rights reserved.

43. Limitations: cycle minimization (1)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(a, c, …)
2 transfer(c, b, …)
3 transfer(b, a, …)
4 transfer(a, b, …)
Slide 43/65. Copyright © 2017. Devexperts LLC. All rights reserved.

44. Limitations: cycle minimization (2)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(a, c, …)
2 transfer(c, b, …)
3 transfer(b, a, …)
4 transfer(a, b, …)
Slide 44/65. Copyright © 2017. Devexperts LLC. All rights reserved.

45. Limitations: cycle minimization (3)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(a, c, …)
2 transfer(c, b, …)
3 transfer(b, a, …)
4 transfer(a, b, …)
Slide 45/65. Copyright © 2017. Devexperts LLC. All rights reserved.

46. Limitations: cycle minimization (4)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(a, c, …)
2 transfer(c, b, …)
3 transfer(b, a, …)
4 transfer(a, b, …)
Slide 46/65. Copyright © 2017. Devexperts LLC. All rights reserved.

47. Limitation: cycle minimization (3)
• Edge (𝑣, 𝑢) has formed a cycle
• Minimize cycle 𝑢, … , 𝑣 ⇔ minimize path 𝑢 ↝ 𝑣
- Can be achieved via BFS
• Usually cycle length is 2 or 3
• Current implementation skips this part
Slide 47/65. Copyright © 2017. Devexperts LLC. All rights reserved.

48. Limitations: independent cycles
• Logically independent cycles:
- 𝑎, 𝑐, 𝑏
- 𝑎, 𝑏
• Independent cycle is ignored due to minimization principle
• One useful cycle is better J
Slide 48/65. Copyright © 2017. Devexperts LLC. All rights reserved.

49. Limitations: single threaded and guarded cycles
• Single threaded cycle
Lock a, b
1 a.lock()
2 b.lock()
3 unlock(a, b)
4 b.lock()
5 a.lock()
6 unlock(a, b)
Slide 49/65. Copyright © 2017. Devexperts LLC. All rights reserved.

50. Limitations: single threaded and guarded cycles
• Guarded cycle
Thread 1 Thread 2
1 g.lock()
2 a.lock()
3 b.lock()
4 unlock(a, b)
5 g.unlock()
6 g.lock()
7 b.lock()
8 a.lock()
9 unlock(a, b)
10 g.unlock()
Slide 50/65. Copyright © 2017. Devexperts LLC. All rights reserved.

51. Limitations: single threaded and guarded cycles
• They are still lock hierarchy violation
• Such potential deadlock may become possible after code
refactoring
Slide 51/65. Copyright © 2017. Devexperts LLC. All rights reserved.

52. IMPLEMENTATION

53. Dl-Check
• Implemented as java agent
- java -javaagent:dlcheck.jar -jar your_app.jar
- Can be used with Junit: -Ddlcheck.fail=true
• Inserts analysis code into classes at run-time
Slide 53/65. Copyright © 2017. Devexperts LLC. All rights reserved.

54. Dl-Check output example
==========================
!!! Potential deadlock !!!
==========================
### Cycle in lock graph: ###
Lock ReentrantLock@75915908 was acquired at:
com/intellij/ide/util/treeView/AbstractTreeUi.acquireLock(AbstractTreeUi.java:2464)
com/intellij/ide/util/treeView/AbstractTreeUi.attemptLock(AbstractTreeUi.java:2460)
Lock ProjectViewTreeUpdater@46e87eab was acquired at:
com/intellij/ide/util/treeView/AbstractTreeUpdater.reset(AbstractTreeUpdater.java:415)
com/intellij/ide/util/treeView/AbstractTreeUpdater.getUpdateCount(AbstractTreeUpdater.java:344)
com/intellij/ide/util/treeView/AbstractTreeUpdater.performUpdate(AbstractTreeUpdater.java:242)
com/intellij/ide/util/treeView/AbstractTreeUpdater.isEnqueuedToUpdate(AbstractTreeUpdater.java:380)
com/intellij/ide/util/treeView/AbstractTreeUpdater.cancelAllRequests(AbstractTreeUpdater.java:326)
### Current lock stack: ###
Lock Object@5cbe2bca was acquired at:
com/intellij/openapi/application/impl/LaterInvocator$FlushQueue.a(LaterInvocator.java:320)
Lock ReentrantLock@75915908 was acquired at:
com/intellij/ide/util/treeView/AbstractTreeUi.acquireLock(AbstractTreeUi.java:2464)
com/intellij/ide/util/treeView/AbstractTreeUi.attemptLock(AbstractTreeUi.java:2460)
### Current stacktrace: ###
com.intellij.ide.util.treeView.AbstractTreeUpdater.cancelAllRequests(AbstractTreeUpdater.java:326)
com.intellij.ide.util.treeView.AbstractTreeUi.releaseNow(AbstractTreeUi.java:457)
com.intellij.ide.util.treeView.AbstractTreeUi.access$1400(AbstractTreeUi.java:66)
com.intellij.ide.util.treeView.AbstractTreeUi$12.perform(AbstractTreeUi.java:438)
...
Slide 54/65. Copyright © 2017. Devexperts LLC. All rights reserved.

55. Byte-code instrumentation
• Captures lock acquire and release operations:
- After MONITORENTER and before MONITOREXIT instructions
- At the beginning and the end of synchronized method
- java.util.concurrent.locks.Lock
• After lock method
• After successful tryLock method invocation
• Before unlock method
Slide 55/65. Copyright © 2017. Devexperts LLC. All rights reserved.

56. Scalability
• MNR algorithm is NOT concurrent
• Read-write lock
- Read lock for read-only operations and current node modification
- Write lock for topological order modification
- SWMR (single-writer multi-reader) data structures
Slide 56/65. Copyright © 2017. Devexperts LLC. All rights reserved.

57. Memory management
• Java has a Garbage Collector
• Old lock instances and nodes should be collected by GC
• WeakReference is used for internal data structures
Slide 57/65. Copyright © 2017. Devexperts LLC. All rights reserved.

58. EVALUATION

59. Benchmarks
• SpecJVM2008: Apache Derby (4 and 40 threads)
• DaCapo: Apache Lucene
• DaCapo: Banking application
• Fine-Grained (10 threads, 100 and 10’000 locks)
- Like transfer(from, to, amount) from examples
• …
Slide 59/65. Copyright © 2017. Devexperts LLC. All rights reserved.

60. Memory usage impact
1
1,07 1,06
1
1,61
1,34
0,61
1,22
1 1
0,74
1,12
1,35
1
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
Derby 1 Derby 2 Lucene Bank FG 1 FG 2
INCREASE FACTOR
Dl-Check Jcarder MulticoreSDK
Slide 60/65. Copyright © 2017. Devexperts LLC. All rights reserved.

61. Performance impact
1,53
1,76
1,03
2,6
4,29
18,05
9,7
128,2
1,25
2,6
7,3
120,71
40,33
3,25
1
2
4
8
16
32
64
128
Derby 1 Derby 2 Lucene Bank FG 1 FG 2
SLOWDOWN FACTOR
Dl-Check Jcarder MulticoreSDK
Slide 61/65. Copyright © 2017. Devexperts LLC. All rights reserved.

62. CONCLUSION

63. Summary
• Algorithm to detect potential deadlocks at run-time
• Dl-Check tool has been implemented
• https://github.com/Devexperts/dlcheck
• Future work:
- Lock grouping feature
- Contracts to describe lock acquisition rules
Slide 63/65. Copyright © 2017. Devexperts LLC. All rights reserved.

64. Thank you for your attention!
Slide 64/65. Copyright © 2017. Devexperts LLC. All rights reserved.

65. Dl-Check: dynamic potential deadlock
detection tool for Java programs
Nikita Koval1,2 Dmitry Tsitelov2 Roman Elizarov2
1ITMO University, Computer Technology Department,
St. Petersburg, Russia
koval@rain.ifmo.ru
2Devexperts, LLC, St. Petersburg, Russia,
dxlab@devexperts.com
TMPA Conference, March 2017

66. Topological order: extra
• Can be maintained in a single iteration in case no cycles are formed
• Already acquired locks are ordered already
• Edge from the rightest node should be used
Slide 66/65. Copyright © 2017. Devexperts LLC. All rights reserved.
...
1 a.lock()
2 b.lock()
3 c.lock()
...
Topological order

67. Topological order: example (0)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Slide 67/65. Copyright © 2017. Devexperts LLC. All rights reserved.

68. Topological order: example (1)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Affected region
Slide 68/65. Copyright © 2017. Devexperts LLC. All rights reserved.

69. Topological order: example (2)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Affected region
Slide 69/65. Copyright © 2017. Devexperts LLC. All rights reserved.

70. Topological order: example (3)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Affected region
Slide 70/65. Copyright © 2017. Devexperts LLC. All rights reserved.

71. Topological order: example (4)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Affected region
Slide 71/65. Copyright © 2017. Devexperts LLC. All rights reserved.

72. Topological order: example (4)
void transfer(Account from,
Account to,
int amount) {
from.lock()
to.lock()
// Do transfer
unlock(from, to)
}
1 transfer(d, b)
2 transfer(d, c)
3 transfer(c, d)
4 transfer(e, a)
5 transfer(b, a)
Affected region
Slide 72/65. Copyright © 2017. Devexperts LLC. All rights reserved.