Vortrag auf dem Objektforum Karlsruhe über Multi-Core-Programmierung auf der JVM. Beispiele in Java und Groovy. Alternative Paradigmen.

1. Mein paralleles Leben
als Java-Programmierer

2. Johannes Link
johanneslink.net

3. Stephan Mosel - http://www.flickr.com/photos/moe/9474926/

4. 2000

6. public class MyClass {
private volatile String myProp = "";
public synchronized String getMyProp() {
return myProp;
}
public void setMyProp(String value) {
synchronized (this) {
myProp = value;
this.notifyAll();
}
}
public synchronized void waitUntilPropNotEmpty()
throws InterruptedException {
while (myProp.equals("")) {
this.wait();
}
}
}

7. public class MyClassTest...
private volatile boolean succeeded = false;
@Test public void waitingForAValue() throws Exception {
final MyClass my = new MyClass();
Thread myThread = new Thread(new Runnable() {
public void run() {
try {
my.waitUntilPropNotEmpty();
succeeded = true;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
});
myThread.start();
my.setMyProp("");
assertFalse(succeeded);
my.setMyProp("test");
myThread.join();
assertTrue(succeeded);
}

8. Angenehme Position des
Halbwissens

9. Angenehme Position des
Halbwissens
"Nebenläufigkeit wird
völlig überbewertet"

10. Angenehme Position des
Halbwissens
"Nebenläufigkeit wird
völlig überbewertet"
"Das erledigen die
Frameworks für mich"

11. Angenehme Position des
Halbwissens
"Nebenläufigkeit wird
völlig überbewertet"
"Das erledigen die
Frameworks für mich"
"Ich trenne meine Fachlogik von
Nebenläufigkeit und Threading"

12. Angenehme Position des
Halbwissens
"Nebenläufigkeit wird
völlig überbewertet"
"Das erledigen die
Frameworks für mich"
"Ich trenne meine Fachlogik von
Nebenläufigkeit und Threading"
"Ich denke mal ganz intensiv
darüber nach und dann
funktioniert das"

13. Kein kostenloses
Mittagessen mehr...

14. aus Herb Sutter: "The free lunch is over"

15. "Applications will increasingly need to be
concurrent if they want to fully exploit
continuing exponential CPU throughput
gains."
Herb Sutter

19. Was ist das Problem?

20. Was ist das Problem?
• Safety:
Nothing bad ever happens

21. Was ist das Problem?
• Safety:
Nothing bad ever happens
• Liveness:
Something good eventually happens

22. Was ist das Problem?
• Safety:
Nothing bad ever happens
• Liveness:
Something good eventually happens
• Performance:
Things happen faster

23. Safety - Alles ist korrekt
public class Counter {
private long count = 0;
public long value() {
return count;
}
public void inc() {
count++;
}
}
Counter counter = new Counter();
//in Thread A:
counter.inc();
//in Thread B:
counter.inc();
//danach:
assert counter.value() == 2;

24. Safety - Alles ist korrekt
public class Counter {
private long count = 0;
public long value() { counter.inc():
return count;
}
public void inc() { temp = counter.count
count++;
}
} temp = temp + 1
Counter counter = new Counter();
//in Thread A: counter.count = temp
counter.inc();
//in Thread B:
counter.inc();
//danach:
assert counter.value() == 2;

25. Safety - Alles ist korrekt
public class Counter {
private long count = 0;
public long value() {
return count;
}
public void inc() {
count++;
}
}
Counter counter = new Counter();
//in Thread A:
counter.inc();
//in Thread B:
counter.inc();
//danach:
assert counter.value() == 2;

26. Safety - Alles ist korrekt
public class Counter { Thread A: Thread B:
private long count = 0;
public long value() { temp = 0
return count;
}
public void inc() { temp = 0 + 1
count++;
}
} count = 1
Counter counter = new Counter(); temp = 1
//in Thread A:
counter.inc();
temp = 1 + 1
//in Thread B:
counter.inc();
//danach: count = 2
assert counter.value() == 2;

27. Safety - Alles ist korrekt
public class Counter {
private long count = 0;
public long value() {
return count;
}
public void inc() {
count++;
}
}
Counter counter = new Counter();
//in Thread A:
counter.inc();
//in Thread B:
counter.inc();
//danach:
assert counter.value() == 2;

28. Safety - Alles ist korrekt
public class Counter { Thread A: Thread B:
private long count = 0;
public long value() { temp = 0
return count;
}
public void inc() { temp = 0 + 1
count++;
}
} temp = 0
Counter counter = new Counter();
count = 1
//in Thread A:
counter.inc();
temp = 0 + 1
//in Thread B:
counter.inc();
//danach: count = 1
assert counter.value() == 2;

30. Thread A: Thread B:
Step A.1 Step B.1
Step A.2
Step B.2
Step A.3
Step B.3
Step A.4 Step B.4
Step A.5

32. Thread A: Thread B:
Step A.1 Step B.1
Step A.3
Step B.3
Step A.2
Step B.2
Step A.5 Step B.4
Step A.4

33. Was bedeutet korrekt
in einem
nebenläufigen
Programm?

34. Synchronisation
nebenläufiger Objekte
Bestimmte Programmbereiche werden
durch Schlösser (Lock) in eine definierte
sequenzielle Reihenfolge gebracht

35. Locks
public class LockedCounter { Thread A: Thread B:
private long count = 0;
private Lock lock lock.lock()
= new ReentrantLock();
public long value() {
lock.lock(); temp = 0 lock.lock()
long value = count;
lock.unlock(); muss warten
return value;
}
lock.unlock()
public void inc() {
lock.lock(); temp = 1
count++;
lock.unlock();
}
} count = 2
lock.unlock()

36. Locks sind nicht umsonst

37. Locks sind nicht umsonst
• Sie bergen das Risiko von Deadlocks

38. Locks sind nicht umsonst
• Sie bergen das Risiko von Deadlocks
• Sie führen zu sequenzialisierter
Programmausführung

39. Locks sind nicht umsonst
• Sie bergen das Risiko von Deadlocks
• Sie führen zu sequenzialisierter
Programmausführung
• Sie benötigen zusätzliche
Prozessorzyklen
‣ Basieren auf primitiven Operationen (TAS
oder CAS), welche (oft) auf "richtiges"
Memory zugreifen müssen

40. Caching, Memory & Co
Prozessor Prozessor
Core Core
L1-Cache L1-Cache
L2-Cache
Memory

41. Caching, Memory & Co
Prozessor Prozessor
Core Core
1-2
L1-Cache L1-Cache
L2-Cache
Memory

42. Caching, Memory & Co
Prozessor Prozessor
Core Core
20-30 1-2
L1-Cache L1-Cache
L2-Cache
Memory

43. Caching, Memory & Co
Prozessor Prozessor
Core Core
20-30 1-2
L1-Cache L1-Cache
L2-Cache
300-400
Zyklen
Memory

45. Wie machen wir ein
Objekt für andere
Threads sichtbar?

46. Prozessor
Core Core
L1-Cache L1-Cache
L2-Cache
Memory

47. Prozessor
Unshared Core Core
Object L1-Cache L1-Cache
L2-Cache
Memory

48. Prozessor
Unshared Core Core
Object L1-Cache L1-Cache
L2-Cache
Shared Object
Memory

49. Sicheres Publizieren -
Safe Publication
• Initialisierung in statischem Initializer
• Speichern in volatile-Feld oder in
AtomicReference
• Ein unveränderliches Objekt
• Speichern in einem Feld, das vollständig
durch einen Lock abgesichert ist

50. Grundsätze für die
Verwendung von Locks
Halte genau dann einen Lock,

51. Grundsätze für die
Verwendung von Locks
Halte genau dann einen Lock,
• wenn du auf gemeinsamen und veränder-
lichen Zustand zugreifst

52. Grundsätze für die
Verwendung von Locks
Halte genau dann einen Lock,
• wenn du auf gemeinsamen und veränder-
lichen Zustand zugreifst
• wenn du atomare Operationen ausführst
‣ check then act
‣ read-modify-write

53. Grundsätze für die
Verwendung von Locks
Halte genau dann einen Lock,
• wenn du auf gemeinsamen und veränder-
lichen Zustand zugreifst
• wenn du atomare Operationen ausführst
‣ check then act
‣ read-modify-write
Halte den Lock nicht länger als nötig

54. Liveness - Jeder sollte an
die Reihe kommen
• Gefahr 1: Deadlocks
• Gefahr 2: Starvation

55. Deadlock
public class SimpleDeadlock...
private final Object left Thread A: Thread B:
= new Object();
private final Object right lock left
= new Object();
public void leftRight() { lock right
synchronized (left) {
synchronized (right) { try to
doSomething(); lock right
} try to
} lock left
}
public void rightLeft() {
synchronized (right) {
synchronized (left) { wait for ever
doSomething();
} wait for ever
}
}

56. Starvation
Bei hohem "Wettbewerb" (contention) um
die gleiche Ressource (z.B. Lock)
kommen nicht alle wartenden Threads an
die Reihe

57. Performance
• Mehr Prozessoren/Kerne sollten zu
besserer Performance führen
‣ Besseres Antwortverhalten durch
Verlagerung lang-laufender Berechnungen
in parallele Threads
‣ Höherer Durchsatz durch Aufteilung von
Berechnungen in mehrere Threads

58. Amdahl's Law

59. Amdahl's Law
F: nicht parallelisierbare Anteil eines Programms
N: Anzahl der Kerne / Prozessoren

60. F = 0,2
5.00
3.75
Beschleunigung
2.50
1.25
0
1 2 3 4 5 10 20 100
Anzahl der Kerne / Prozessoren

61. Wie parallelisiert man ein
Programm?

62. Wie parallelisiert man ein
Programm?
• Parallelisierung des Kontrollflusses

63. Wie parallelisiert man ein
Programm?
• Parallelisierung des Kontrollflusses
• Parallellisierung der Daten

64. Parallelisierung des Kontrollflusses
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6

65. Parallelisierung des Kontrollflusses
Step 1 Step 1
Step 2 Step 2 Step 3
Step 3
Step 4a Step 4b Step 4c
Step 4
Step 5 Step 6
Step 5
Step 6

66. Rekursive Zerlegung des
Kontrollflusses (Fork/Join)
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6

67. Rekursive Zerlegung des
Kontrollflusses (Fork/Join)
Step 1 Step 1
Step 2
Steps 2-5
Step 3
2-5.1 2-5.2 2-5.n
Step 4
2-5.1.1 2-5.1.2 2-5.1.n
Step 5
Step 6
Step 6

68. Parallelisierung der Daten
for 1..n do
Step 1
Step 2
Step 3
Step 4
Step 5

69. Parallelisierung der Daten
for 1..n do for each element do in parallel:
Step 1 Step 1
Step 1
Step 1
Step 1
Step 1
Step 2 Step 2
Step 2
Step 2
Step 2
Step 2
Step 3 Step 3
Step 3
Step 3
Step 3
Step 3
Step 4 Step 4
Step 4
Step 4
Step 4
Step 4
Step 5 Step 5
Step 5
Step 5
Step 5
Step 5

70. java.util.concurrent[.a
tomic|locks]

71. Locks und Conditions
<<Interface>> <<Interface>>
Lock Condition
creates
lock() await()
lockInterruptibly() await(timeout)
tryLock(timeout) signal()
unlock() signalAll()
ReentrantLock

72. public class MyNewClass...
private String myProp = "";
private Lock lock = new ReentrantLock();
private Condition propNotEmpty = lock.newCondition();
public String getMyProp() {
lock.lock();
try {
return myProp;
} finally {lock.unlock();}
}
public void setMyProp(String value) {
lock.lock();
try {
myProp = value;
propNotEmpty.signalAll();
} finally {lock.unlock();}
}
public void waitUntilPropNotEmpty() throws InterruptedException {
lock.lock();
try {
while (myProp.equals("")) {
propNotEmpty.await();
}
} finally {lock.unlock();}
}

73. public class MyNewClass...
private String myProp = "";
private Lock lock = new ReentrantLock();
private Condition propNotEmpty = lock.newCondition();
public String getMyProp() {
lock.lock();
try {
return myProp;
} finally {lock.unlock();}
}
public void setMyProp(String value) {
lock.lock();
try {
myProp = value;
propNotEmpty.signalAll();
} finally {lock.unlock();}
}
public void waitUntilPropNotEmpty() throws InterruptedException {
lock.lock();
try {
while (myProp.equals("")) {
propNotEmpty.await();
}
} finally {lock.unlock();}
}

74. public class MyNewClass...
private String myProp = "";
private Lock lock = new ReentrantLock();
private Condition propNotEmpty = lock.newCondition();
public String getMyProp() {
lock.lock();
try {
return myProp;
} finally {lock.unlock();}
}
public void setMyProp(String value) {
lock.lock();
try {
myProp = value;
propNotEmpty.signalAll();
} finally {lock.unlock();}
}
public void waitUntilPropNotEmpty() throws InterruptedException {
lock.lock();
try {
while (myProp.equals("")) {
propNotEmpty.await();
}
} finally {lock.unlock();}
}

75. Implizite oder explizite
Locks / Conditions
• Verwende implizite Locks und Conditions,
wenn dir deren Feature-Set genügt
‣ Performance seit Java 6 praktisch gleich
• Verwende explizite Locks und Conditions,
wenn du mehr brauchst
‣ Unterbrechbarkeit
‣ tryLock()
‣ Timeouts
‣ Mehr als eine Condition-Queue

76. Das Executor-Framework
Nie wieder new Thread(...).start() !
<<Interface>>
Executor
<<Interface>>
execute(Runnable) Callable<T>
call(): T
<<Interface>>
ExecutorService
<<Interface>>
submit(Runnable):Future<?>
Future<T>
submit(Callable<T>):Future<T>
shutdown() cancel(mayInterrupt)
awaitTermination(timeout) get(): T
get(timeout): T

77. public class MyNewClassTest...
private volatile boolean succeeded = false;
@Test
public void waitingForAValue() throws Exception {
final MyNewClass my = new MyNewClass();
ExecutorService executor = Executors.newCachedThreadPool();
Runnable task = new Runnable() {
@Override
public void run() {
try {
my.waitUntilPropNotEmpty();
succeeded = true;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
};
Future<?> result = executor.submit(task);
my.setMyProp("");
assertFalse(succeeded);
my.setMyProp("test");
result.get(); //wait for end of task
assertTrue(succeeded);
}

78. public class MyNewClassTest...
private volatile boolean succeeded = false;
@Test
public void waitingForAValue() throws Exception {
final MyNewClass my = new MyNewClass();
ExecutorService executor = Executors.newCachedThreadPool();
Runnable task = new Runnable() {
@Override
public void run() {
try {
my.waitUntilPropNotEmpty();
succeeded = true;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
};
Future<?> result = executor.submit(task);
my.setMyProp("");
assertFalse(succeeded);
my.setMyProp("test");
result.get(); //wait for end of task
assertTrue(succeeded);
}

79. public class MyNewClassTest...
private volatile boolean succeeded = false;
@Test
public void waitingForAValue() throws Exception {
final MyNewClass my = new MyNewClass();
ExecutorService executor = Executors.newCachedThreadPool();
Runnable task = new Runnable() {
@Override
public void run() {
try {
my.waitUntilPropNotEmpty();
succeeded = true;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
};
Future<?> result = executor.submit(task);
my.setMyProp("");
assertFalse(succeeded);
my.setMyProp("test");
result.get(); //wait for end of task
assertTrue(succeeded);
}

80. Atomics
public class SynchronizedCounter...
private long count = 0;
public synchronized long value() {
return count;
}
public synchronized void inc() {
count++;
}

81. Atomics
public class SynchronizedCounter...
private long count = 0;
public synchronized long value() {
return count;
}
public synchronized void inc() {
count++;
}
public class AtomicCounter...
private AtomicLong count = new AtomicLong(0);
public long value() {
return count.longValue();
}
public void inc() {
count.incrementAndGet();
}

82. Compare and Set
public class HandmadeAtomicReference<V>...
private V ref;
public HandmadeAtomicReference(V initialValue) {...}
public synchronized V get() { return ref; }
/**
* Atomically sets the value to the given updated value
* if the current value {@code ==} the expected value.
* @param expect the expected value
* @param update the new value
* @return true if successful.
*/
public synchronized boolean compareAndSet(V expect, V update) {
if (ref != expect)
return false;
ref = update;
return true;
}

83. Und noch mehr...
• Concurrent Collections
• BlockingQueue
• Latches, Barriers, Exchangers & Co

84. Mein Lieblingsbeispiel:
Banking
Bank
createNewAccountFor(customer): Account
accountByNumber(long accNum): Account
allAccountNumbers(): Collection<long>
Account
accountNumber: long
customer: String
balance: BigDecimal
deposit(amount)
withdraw(amount)

85. Mein Lieblingsbeispiel:
Banking
Bank
createNewAccountFor(customer): Account
accountByNumber(long accNum): Account
allAccountNumbers(): Collection<long>
uses
Account
MoneyTransfer
accountNumber: long
customer: String amount: BigDecimal
balance: BigDecimal from, to: long
deposit(amount) execute(Bank bank)
withdraw(amount)

86. public class Account {
private BigDecimal balance = BigDecimal.ZERO;
private final long accountNumber;
private final String customer;
public Account(long accountNumber, String customer) {...}
public void deposit(BigDecimal amount) {
balance = balance.add(amount);
}
public void withdraw(BigDecimal amount) {
balance = balance.subtract(amount);
}
public BigDecimal getBalance() {
return balance;
}
public long getAccountNumber() {
return accountNumber;
}
public String getCustomer() {
return customer;
}
}

87. public class Bank {
private Map<Long, Account> accounts = new HashMap<Long, Account>();
private long lastAccountNumber = 0;
public Account createNewAccountForString(String customer) {
Account account = new Account(++lastAccountNumber, customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

88. public class AccountCreationTest extends ParallelTestCase...
private volatile Bank bank = new Bank();
@Test
public void createAccountsInManyThreads() throws Exception {
final int numberOfAccounts = 100;
final AtomicInteger account = new AtomicInteger(0);
Runnable createAccountTask = new Runnable() {
@Override
public void run() {
String customer = "c" + account.incrementAndGet();
long accountNumber = bank.createNewAccountForString(
customer).getAccountNumber();
assertEquals(customer, bank.accountByNumber(
accountNumber).getCustomer());
}
};
runInParallelThreads(numberOfAccounts, createAccountTask);
assertAllAccountsHaveBeenCreated(numberOfAccounts);
}

89. "No account with number 99"
public class Bank {
private Map<Long, Account> accounts = new HashMap<Long, Account>();
private long lastAccountNumber = 0;
public Account createNewAccountForString(String customer) {
Account account = new Account(++lastAccountNumber, customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

90. public class Bank {
private Map<Long, Account> accounts = new HashMap<Long, Account>();
private AtomicLong lastAccountNumber = new AtomicLong(0L);
public Account createNewAccountForString(String customer) {
Account account =
new Account(lastAccountNumber.incrementAndGet(), customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

91. NullPointerException
public class Bank {
private Map<Long, Account> accounts = new HashMap<Long, Account>();
private AtomicLong lastAccountNumber = new AtomicLong(0L);
public Account createNewAccountForString(String customer) {
Account account =
new Account(lastAccountNumber.incrementAndGet(), customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

92. public class Bank {
private final Map<Long, Account> accounts =
new ConcurrentHashMap<Long, Account>();
private final AtomicLong lastAccountNumber = new AtomicLong(0L);
public Account createNewAccountForString(String customer) {
Account account =
new Account(lastAccountNumber.incrementAndGet(), customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

93. ok
public class Bank {
private final Map<Long, Account> accounts =
new ConcurrentHashMap<Long, Account>();
private final AtomicLong lastAccountNumber = new AtomicLong(0L);
public Account createNewAccountForString(String customer) {
Account account =
new Account(lastAccountNumber.incrementAndGet(), customer);
accounts.put(account.getAccountNumber(), account);
return account;
}
public Account accountByNumber(long accountNumber) {
return accounts.get(accountNumber);
}
}

94. public class Account...
private final AtomicReference<BigDecimal> balance =
new AtomicReference<BigDecimal>(BigDecimal.ZERO);
public void deposit(BigDecimal amount) {
while (true) {
BigDecimal oldAmount = balance.get();
BigDecimal newAmount = oldAmount.add(amount);
if (balance.compareAndSet(oldAmount, newAmount))
return;
}
}
public void withdraw(BigDecimal amount) {
while (true) {
BigDecimal oldAmount = balance.get();
BigDecimal newAmount = oldAmount.subtract(amount);
if (balance.compareAndSet(oldAmount, newAmount))
return;
}
}
public BigDecimal getBalance() {
return balance.get();
}

95. public class Account...
private final AtomicReference<BigDecimal> balance =
new AtomicReference<BigDecimal>(BigDecimal.ZERO);
public void deposit(BigDecimal amount) {
while (true) {
BigDecimal oldAmount = balance.get();
BigDecimal newAmount = oldAmount.add(amount);
if (balance.compareAndSet(oldAmount, newAmount))
return;
}
}
public void withdraw(BigDecimal amount) {
while (true) {
BigDecimal oldAmount = balance.get();
BigDecimal newAmount = oldAmount.subtract(amount);
if (balance.compareAndSet(oldAmount, newAmount))
return;
}
}
public BigDecimal getBalance() {
return balance.get();
}

96. public class Account...
private BigDecimal balance = BigDecimal.ZERO;
public synchronized void deposit(BigDecimal amount) {
balance = balance.add(amount);
}
public synchronized void withdraw(BigDecimal amount) {
balance = balance.subtract(amount);
}
public synchronized BigDecimal getBalance() {
return balance;
}

97. public class MoneyTransfer {
private final BigDecimal amount;
private final long from;
private final long to;
public MoneyTransfer(BigDecimal amount, long from, long to) {
this.amount = amount;
this.from = from;
this.to = to;
}
public void execute(Bank bank) {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
if (source.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
source.withdraw(amount);
target.deposit(amount);
}
}

98. public class MoneyTransfer {
private final BigDecimal amount;
private final long from;
private final long to;
public MoneyTransfer(BigDecimal amount, long from, long to) {
this.amount = amount;
this.from = from;
this.to = to;
}
synchronized bank) {
public void execute(Bank void execute(Bank bank) {
(
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
if (source.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
source.withdraw(amount);
target.deposit(amount);
}
}

99. public class MoneyTransfer...
public void execute(Bank bank) {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
synchronized (source) {
synchronized (target) {
doTransfer(source, target);
}
}
}
private void doTransfer(Account source, Account target) {
if (source.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
source.withdraw(amount);
target.deposit(amount);
}

100. public class MoneyTransfer...
public void execute(Bank bank) {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
synchronized (source) {
synchronized (target) {
doTransfer(source, target);
(
}
}
}
private void doTransfer(Account source, Account target) {
if (source.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
source.withdraw(amount);
target.deposit(amount);
}
// Thread A:
new MoneyTransfer(new BigDecimal(2), 234, 789).execute(bank);
// Thread B:
new MoneyTransfer(new BigDecimal(2), 789, 234).execute(bank);

101. public class MoneyTransfer...
public void execute(Bank bank) {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
Object[] locks = new Object[] { source, target };
Arrays.sort(locks);
synchronized (locks[0]) {
synchronized (locks[1]) {
doTransfer(source, target);
}
}
}
public class Account implements Comparable<Account>...
public int compareTo(Account other) {
return new Long(accountNumber).
compareTo(new Long(other.accountNumber));
}

102. Für den normal sterblichen
Entwickler ist die Erstellung
korrekter Multi-Thread-
Programme außerhalb ihrer
Fähigkeiten

103. public class ValueHolder {
private List<Listener> listeners = new LinkedList<Listener>();
private int value;
public static interface Listener {
public void valueChanged(int newValue);
}
public void addListener(Listener listener) {
listeners.add(listener);
}
public void setValue(int newValue) {
value = newValue;
for (Listener each : listeners) {
each.valueChanged(newValue);
}
}
}
The Problem with Threads
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

104. Zugrundeliegende
Programmiermodell
Shared mutable state (aka objects)
is accessed in multiple concurrent threads,
and we use locks to synchronize /
sequentialize access to the state

105. Das Objekt wird zur
"undichten" Abstraktion
Um aus einzelnen thread-sicheren Objekten
komplexere thread-sichere Objekte zu
bauen, muss der Locking-Mechanismus der
Einzelobjekte bekannt sein
‣ Verletzt Prinzip der Kapselung
‣ Verletzt Prinzip der Modularisierung

106. Können uns andere
Programmierparadigmen
retten?

107. Alternative Paradigmen
• Transactional Memory
• Immutability
• Message Passing
• Parallel Collection Processing
• Dataflow Concurrency

108. Transactional Memory
(TM)
• Heap als transaktionale Datenmenge
• Transaktionseigenschaften ähnlich wie
bei einer Datenbank (ACID)
• Optimistische Transaktionen
• Transaktionen werden bei einer
Kollision automatisch wiederholt
• Transaktionen können geschachtelt und
komponiert werden

109. public class Account...
public void deposit(BigDecimal amount) {
atomic {
balance = balance.add(amount);
}
}
public void withdraw(BigDecimal amount) {
atomic {
balance = balance.subtract(amount);
}
}

110. public class Account...
public void deposit(BigDecimal amount) {
atomic {
balance = balance.add(amount);
}
}
public void withdraw(BigDecimal amount) {
atomic {
balance = balance.subtract(amount);
}
}

111. public class Account...
public void deposit(BigDecimal amount) {
atomic {
balance = balance.add(amount);
}
}
public void withdraw(BigDecimal amount) {
atomic {
balance = balance.subtract(amount);
}
}
public class MoneyTransfer...
public void execute(Bank bank) {
atomic {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
if (source.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
source.withdraw(amount);
target.deposit(amount);
}
}

112. Eigenschaften von TM
• Vorteile:
‣ Wir können weiter in shared state und
Transaktionen denken
‣ Die korrekte Verwendung ist wesentlich
einfacher als bei Locks: Deadlocks sind
ausgeschlossen!
• Nachteile:
‣ Keinerlei Hilfe, wie wir unser sequenzielles
Programm parallelisieren
‣ Der Fortschritt ist nicht garantiert. Livelocks
sind möglich
‣ Die performante Implementierung ist noch
Forschungsthema

113. TM-Implementierungen
• Hardware Transactional Memory
• Software Transactional Memory
‣ Clojure: Programmiersprache auf der JVM,
die STM eingebaut hat
‣ Java-STM-Frameworks:
Deuce, Akka, Multiverse

114. Immutability

115. Immutability
• Ohne veränderlichen Zustand, müssen
Veränderungen auch nicht
synchronisiert werden

116. Immutability
• Ohne veränderlichen Zustand, müssen
Veränderungen auch nicht
synchronisiert werden
• Systeme haben aber doch einen Zustand
der sich ändert, oder?

117. Immutability
• Ohne veränderlichen Zustand, müssen
Veränderungen auch nicht
synchronisiert werden
• Systeme haben aber doch einen Zustand
der sich ändert, oder?
• Trick: Wir unterscheiden zwischen
unveränderlichen Werten (values) und
einer bestimmten Entity zugeordnenten
aktuellen Wert

118. @Immutable
class Account {
BigDecimal balance
long accountNumber
String customer
static Account create(long accountNumber, String customer) {
new Account(balance: 0.0, accountNumber: accountNumber,
customer: customer)
}
Account deposit(amount) {
cloneWithChange(balance: balance + amount)
}
Account withdraw(amount) {
cloneWithChange(balance: balance - amount)
}
private Account cloneWithChange(changes) {
def newProps = ...
new Account(newProps)
}
}

119. @Immutable
class Account...
BigDecimal balance
long accountNumber
String customer
long version
static Account create(long accountNumber, String customer) {
new Account(balance: 0.0, accountNumber: accountNumber,
customer: customer, version: 0)
}
Account incrementVersion() {
cloneWithChange(version: version + 1)
}
Account deposit(amount) {
cloneWithChange(balance: balance + amount)
}
Account withdraw(amount) {
cloneWithChange(balance: balance - amount)
}

120. class Bank...
private final accounts = new ConcurrentHashMap()
Account createNewAccountFor(String customer) {
Account account =
Account.create(nextAccountNumber(), customer).incrementVersion();
accounts[account.getAccountNumber()] = account
}
Account accountByNumber(long accountNumber) {
accounts[accountNumber]
}
synchronized boolean update(Account... accountsToUpdate) {
if (accountsToUpdate.any {acc ->
acc.version != accounts[acc.accountNumber]?.version
}) {
return false
}
accountsToUpdate.each {acc ->
accounts[it.accountNumber] = it.incrementVersion()
}
return true
}

121. @Immutable
class MoneyTransfer {
BigDecimal amount
long from, to
boolean execute(Bank bank) {
while(true) {
Account source = bank.accountByNumber(from);
Account target = bank.accountByNumber(to);
if (source.balance < amount)
return false
source = source.withdraw(amount)
target = target.deposit(amount)
if (bank.update(source, target))
return true
}
}
}

122. Immutability im Großen
• Performante Implementierung von
"Immutable Data Types" ist möglich
• In funktionale Programmiersprachen
sind unveränderliche Werte die Norm
und veränderlicher State die Ausnahme
‣ Beispiel Clojure: Fokus auf unveränderliche
Werte und explizite Mechanismen zur
Manipulation des aktuellen Werts einer
Entity

123. Message Passing - Actors
• Vollständiger Verzicht auf "shared
state"
• Aktoren empfangen und verschicken
Nachrichten
‣ Asynchron und nicht-blockierend
‣ Jeder Actor hat seine "Mailbox"
• Immer nur ein aktiver Thread pro Aktor

124. class BankActor extends AbstractPooledActor...
void act() {
loop {
react { message ->
switch(message) {
case CreateAccount:
createNewAccountFor(message.customer); break
case GetAccount:
accountByNumber(message.accountNumber); break
case GetAllAccountNumbers:
allAccountNumbers(); break
case UpdateAccounts:
update(message.accounts); break
default:
println "${this.class}: I don't understand $message"
} } } }
@Immutable class CreateAccount { String customer }
@Immutable class UpdateAccounts { Account[] accounts }
@Immutable class GetAccount { long accountNumber }
@Immutable class GetAllAccountNumbers {}

125. class BankActor extends AbstractPooledActor...
private accounts = [:]
private lastAccountNumber = 0
void createNewAccountFor(String customer) {
Account account = ...
reply account
}
void accountByNumber(long accountNumber) {
reply accounts[accountNumber]
}
void allAccountNumbers() {
reply accounts.keySet() as List
}
void update(Account[] accountsToUpdate) {
if (accountsToUpdate.any { acc ->
acc.version != accounts[acc.accountNumber]?.version
}) {
reply false
} else {
accountsToUpdate.each {acc ->
accounts[acc.accountNumber] = acc.incrementVersion()
}
reply true
} }

126. class MoneyTransferActor...
BankActor bank
void act() {
...
switch(message) {
case TransferMoney: transferMoney(message); break;
}
void transferMoney(transfer) {
while(true) {
Account source = bank.sendAndWait(new GetAccount(transfer.from));
Account target = bank.sendAndWait(new GetAccount(transfer.to));
if (source.balance < transfer.amount) {
reply new TransferResult(transfer.transferId, false)
break
}
source = source.withdraw(transfer.amount)
target = target.deposit(transfer.amount)
if (bank.sendAndWait(new UpdateAccounts(accounts: [source, target]))) {
reply new TransferResult(transfer.transferId, true)
break
} } }
@Immutable class TransferMoney {
long transferId
BigDecimal amount
long from, to
}

127. Actors - Vorteile
• Unabhängige Aktoren
• Skalierbar
• Verteilbar
• Leichtere Vermeidung von
‣ Race Conditions
‣ Dead Locks
‣ Starvation

128. Fehler-tolerant &
hoch-verfügbar
• Mehrere redundante Aktoren stehen für
die gleiche Aufgabe zur Verfügung
• Organisation in Supervisor-Hierarchien
‣ Kein lokales Exception-Handling, sondern
Neustart eines Aktors im Fehlerfalle

129. Actors - Nachteile
• Nicht geeignet für Probleme, die einen
echten Konsens über gemeinsame
Objekte erfordern
• Kommunikation über asynchrone
Nachrichten ist für viele
Problemstellungen eine Komplizierung

130. Parallele Collections
• Wir arbeiten auf allen Elementen einer
Collection gleichzeitig
• Voraussetzung: Die Einzeloperationen
sind unabhängig voneinander
• Typische parallele Aktionen:
‣ Filtern
‣ Transformieren

131. Beispiel:
Standardabweichung aller
Millionärskonten von
1.000.000
transform filter transform
Kontonummer Saldo Mio-Saldo Diff2Mio
transform filter transform
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
transform Saldo filter Mio-Saldo transform Diff2Mio
sum
Kontonummer
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
Kontonummer transform Saldo filter Mio-Saldo transform Diff2Mio
mier
Kontonummer Saldo Mio-Saldo Diff2Mio
su
m
en
m
ier
en
Std-Dev

132. gpars' parallele Collections
Parallelizer.doParallel(numThreads) {
def allBalances = bank.allAccountNumbers().collectParallel {
return bank.accountByNumber(it).balance
}
def millionaireBalances = allBalances.findAllParallel { it >= MILLION }
def deviations = millionaireBalances.collectParallel { balance ->
def diffToMean = balance - MILLION
return (diffToMean * diffToMean)
}
def count = deviations.size()
def average = Math.sqrt(deviations.sumParallel() / count)
}

133. Collection

134. ..work..
..work..
..work..
Collection Collection
..work..
..work..

135. ..work.. ..work..
..work.. ..work..
..work.. ..work..
Collection Collection
..work.. ..work..
..work.. ..work..

136. MapReduce
• Von Google patentierter Ansatz zur
verteilten Bearbeitung großer
Datencluster
• Name stammt von den map- und reduce-
Funktionen funktionaler Sprachen
• Idee: Einzelne Datensätze werden durch
eine Pipeline von Arbeitsschritten
transformiert (map) und am Ende zu
einem Ergebnis zusammengeführt
(reduce)

137. Data Set
Data Set
Data Set
Data Set
Data Set
Data Set

138. Data Set map Data Set
Data Set map Data Set
Data Set map Data Set
Data Set map Data Set
Data Set map Data Set
Data Set map Data Set

139. Data Set map Data Set
reduce
Data Set map Data Set
Data Set map Data Set reduce
reduce
Data Set map Data Set
reduce
Data Set map Data Set
Result
reduce
Data Set map Data Set

140. Data Set map Data Set
reduce
Data Set map Data Set
Data Set map Data Set reduce
reduce
Data Set map Data Set
reduce
Data Set map Data Set
Result
reduce
Data Set map Data Set

141. Map-Reduce mit gpars
Parallelizer.doParallel(numThreads) {
def deviations = bank.allAccountNumbers().parallel.map {accountNumber ->
bank.accountByNumber(accountNumber).balance
}.filter { balance -> balance >= MILLION }.map {balance ->
def diffToMean = balance - MILLION
(diffToMean * diffToMean)
}
//def sum = deviations.sum()
def sum = deviations.reduce {a,b -> a + b}
def count = deviations.size()
def average = Math.sqrt(sum / count)
}

142. Kritik an MapReduce
• Patentierbarkeit (claim of novelty)
wird angezweifelt
• Wie breit ist der Problemraum, für den
MapReduce sinnvoll angewandt werden
kann?
• Wie sinnvoll ist MapReduce im nicht
verteilten Kontext?

143. Performance-Vergleich
• Hardware:
‣ Intel i7: 4 cores, 8 hyper threads
• Wettbewerber
‣ Sequenziell
‣ Parallel Collections
‣ MapReduce
• Vefahren
‣ jeweils 1 - 8 Threads
‣ jeweils 10 Samples
‣ 1000, 2000, 10.000, 50.000, 100.000 Konten

144. Erwartete Beschleunigung
3.00
2.50
Beschleunigungsfaktor
2.00
1.50
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

145. Beschleunigung bei 1000 Konten
2.00
1.50
Beschleunigungsfaktor
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

146. Beschleunigung bei 2000 Konten
2.00
1.50
Beschleunigungsfaktor
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

147. Beschleunigung bei 10000 Konten
2.00
1.50
Beschleunigungsfaktor
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

148. Beschleunigung bei 50000 Konten
2.00
1.50
Beschleunigungsfaktor
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

149. Beschleunigung bei 100000 Konten
2.00
1.50
Beschleunigungsfaktor
1.00
0.50
0
1 2 3 4 5 6 7 8
Anzahl der Threads
Sequential Parallel Collections MapReduce

150. Data Flows
• Beschreibung der Abhängigkeiten von
Daten untereinander
• Grundkonzept: Dataflow-Variablen
‣ Wert kann nur einmal gebunden werden
‣ Abfrage des Wertes blockiert bis er
gebunden wurde

151. gpars - DataFlows
def x = new DataFlowVariable()
def y = new DataFlowVariable()
def z = new DataFlowVariable()
task { z << x.val + y.val }
task { x << 40 }
task { y << 2 }
assert 42 == z.val

152. gpars - DataFlows
def x = new DataFlowVariable()
def y = new DataFlowVariable()
def z = new DataFlowVariable()
task { z << x.val + y.val }
task { x << 40 }
task { y << 2 }
assert 42 == z.val
def df = new DataFlows()
task { df.z = df.x + df.y }
task { df.x = 40 }
task { df.y = 2 }
assert 42 == df.z

153. Vorteile von Dataflows
• Kein Locking notwendig
• Keine Race-Conditions
• Deterministisch
‣ Deadlocks sind möglich, sie passieren dann
aber immer!
• Kein Unterschied zwischen
sequenziellem und nebenläufigem Code

154. Beispiel: Depotwert
def depot = ['AAPL':10, 'GOOG':2, 'IBM':20, 'ORCL':500]
def stocks = depot.keySet()
def prices = new DataFlows()
def value = new DataFlowVariable()
stocks.each {stock ->
task {
prices[stock] = getStockPrice(stock)
}
}
task {
value << stocks.collect { stock ->
prices[stock] * depot[stock]
}.sum()
}
println value.val

155. Mehr über Data Flows
• Einschränkungen
‣ Nicht für jede Problemstellung geeignet
‣ Berechnungen dürfen keine Seiteneffekte
haben
• Erweiterungen
‣ Data flow streams, Data flow operators
• JVM-Implementierungen
‣ Scala Dataflow, FlowJava (akademisch & tot)

156. Nicht behandelt
• Fork/Join (jsr166y)
• CSP:
Communicating Sequential Processes
• Declarative Concurrency
• und andere...

157. Fazit
• Multi-thread-orientierte und Lock-
basierte Programmierung ist schwierig
‣ Hauptgrund: Thread-sichere Objekte sind
zusammengesetzt nicht komponierbar
• "Immutability" erleichtert das parallele
Leben sehr
• Andere Paradigmen können helfen, der
heilige Kral der Multi-Core-Entwicklung
ist aber (noch) nicht gefunden

158. Links
Zum Lesen
http://www.infoq.com/presentations/
goetz-concurrency-past-present
http://www.slideshare.net/jboner/
state-youre-doing-it-wrong-javaone-2009
http://ajaxonomy.com/2008/news/
toward-better-concurrency
http://igoro.com/archive/
gallery-of-processor-cache-effects/
Zum Ausprobieren
http://gpars.codehaus.org/
http://clojure.org/
http://github.com/jboner/scala-dataflow