Nebenläufigkeit auf der JVM und anderswo

Transcript

1. Nebenläufigkeit auf der JVM (und anderswo) 28. November 2011 ObjektForum

   Stuttgart Johannes Link business@johanneslink.net @johanneslink

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

3. Wir werden uns immer seltener um das Thema Concurrency herumdrücken

   können

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

   • Liveness: Something good eventually happens • Speed & Responsiveness: Things (seem to) happen faster

5. 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; temp = 0 temp = 0 + 1 count = 1 Thread A: Thread B: temp = 0 temp = 0 + 1 count = 1

6. Step A.1 Step A.2 Step A.3 Thread A: Thread B:

   Step B.1 Step B.2 Step A.4 Step A.5 Step B.3 Step B.4

7. Step A.1 Step A.2 Step A.3 Thread A: Thread B:

   Step B.1 Step A.4 Step A.5 Step B.4 Step B.2 Step B.3

8. Step A.1 Step A.3 Step A.2 Thread A: Thread B:

   Step B.1 Step B.3 Step A.5 Step A.4 Step B.2 Step B.4

9. Welche Bedeutung hat konsistent in einem nebenläufigen Programm?

10. Quiescent Consistency In einer "Ruhephase" ist ein Objekt in einem

    Zustand, der einer beliebigen sequentiellen Ausführung aller vorangegangenen Methoden-Aufrufe entspricht

11. Synchronisation nebenläufiger Objekte Bestimmte Programmbereiche werden durch Schlösser (Lock) in

    eine definierte sequenzielle Reihenfolge gebracht

12. Locks public class LockedCounter { private long count = 0;

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

13. 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), und Speicherbarrieren welche (oft) auf "richtiges" Memory zugreifen müssen

14. Caching, Memory & Co Prozessor Core L1/2-Cache L3-Cache Core L1/2-Cache

    Memory Prozessor 1-5 20-30 300-400 Zyklen Unshared Object Shared Object

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

16. Liveness - Jeder sollte an die Reihe kommen • Gefahr

    1: Deadlocks • Gefahr 2: Starvation

17. Lock-ordering Deadlock public class SimpleDeadlock... private final Object left =

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

18. Speed • Mehr Prozessoren/Kerne sollten zu besserer Performance führen ‣

    Responsiveness ‣ Throughput

19. Parallel != Concurrent

20. Responsiveness • Besseres Antwortverhalten durch Verlagerung lang-laufender Aufgaben in parallele

    Threads • Asynchrone Benachrichtigung bei Beendigung / Fortschritt der Berechnung

21. Throughput • Gleichzeitiges Anstoßen mehrerer Aufgaben, um die Gesamtlaufzeit zu

    verkleinern ‣ CPU-bound tasks ‣ I/O-bound tasks

22. Amdahl's Law F: nicht parallelisierbare Anteil eines Programms N: Anzahl

    der Kerne / Prozessoren

23. 0 1,25 2,50 3,75 5,00 1 2 3 4 5

    10 20 100 F = 0,2 Beschleunigung Anzahl der Kerne / Prozessoren

24. Wie parallelisiert man ein Programm? • Embarassingly Parallel? • Übliche

    Strategien ‣ Parallelisierung des Kontrollflusses ‣ Parallellisierung der Daten ‣ Kombination beider Arten

25. Parallelisierung des Kontrollflusses Step 1 Step 2 Step 3 Step

    4 Step 5 Step 6 Step 1 Step 2 Step 3 Step 4a Step 5 Step 6 Step 4b Step 4c

26. Rekursive Zerlegung des Kontrollflusses (Fork/Join) Step 1 Step 2 Step

    3 Step 4 Step 5 Step 6 Step 1 Step 6 Steps 2-5 2-5.1 2-5.2 2-5.n 2-5.1.1 2-5.1.2 2-5.1.n

27. for 1..n do Step 1 Step 2 Step 3 Step

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

28. java.util.concurrent [.atomic|locks]

29. Locks und Conditions <<Interface>> Lock lock() lockInterruptibly() tryLock(timeout) unlock() <<Interface>>

    Condition await() await(timeout) signal() signalAll() creates ReentrantLock

30. public class MyNewClass... private String myProp = ""; private Lock

    lock = new ReentrantLock(); public String getMyProp() { lock.lock(); try { return myProp; } finally {lock.unlock();} } public void setMyProp(String value) { lock.lock(); try { myProp = value; } finally {lock.unlock();} } public class MyNewClass... private String myProp = ""; public synchronized String getMyProp() { return myProp; } public synchronized void setMyProp(String value) { myProp = value; }

31. Das Executor-Framework new Thread(...).start() ! <<Interface>> Executor execute(Runnable) <<Interface>> ExecutorService

    submit(Runnable):Future<?> submit(Callable<T>):Future<T> shutdown() awaitTermination(timeout) <<Interface>> Future<T> cancel(mayInterrupt) get(): T get(timeout): T <<Interface>> Callable<T> call(): T Nie wieder

32. ExecutorService executor = Executors.newCachedThreadPool(); Callable task = new Callable<MyType>() {

    @Override public MyType call() { ... //perform long-running task return new MyType(...); } }; Future<MyType> result = executor.submit(task); ... //do something else result.get(); //wait for end of task Das Executor-Framework Nie wieder new Thread(...).start() !

33. 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(); }

34. Und noch mehr... • Concurrent Collections • BlockingQueue • Latches,

    Barriers, Exchangers & Co • Fork/Join (Java 7)

35. Shelf capacity: int products: List<Product> putIn(product) takeOut(product): boolean isFull(): boolean

    Product type: String Storehouse newShelf(name, size): Shelf getShelf(name): Shelf move(product, from, to): boolean shelves: Map<String, Shelf> name

36. public class Shelf { private int capacity; private List<Product> products

    = new ArrayList<Product>(); public Shelf(int capacity) { this.capacity = capacity; } public List<Product> getProducts() { return products; } public boolean isFull() { return products.size() == capacity; } public void putIn(Product product) { if (isFull()) throw new StorageException("shelf is full."); products.add(product); } public boolean takeOut(Product aBook) { return products.remove(aBook); } }

37. public class Storehouse { private Map<String, Shelf> shelves = new

    HashMap<String, Shelf>(); public Shelf newShelf(String name, int capacity) { Shelf newShelf = new Shelf(capacity); shelves.put(name, newShelf); return newShelf; } public Shelf getShelf(String name) { return shelves.get(name); } }

38. public class ConcurrentShelfCreationTest extends ParallelTestCase { private volatile Storehouse store

    = new Storehouse(); @Test public void createAccountsInManyThreads() throws Exception { final int numberOfShelves = 100; final AtomicInteger shelf = new AtomicInteger(0); Runnable createShelfTask = new Runnable() { @Override public void run() { String shelfName = "n" + shelf.incrementAndGet(); Shelf shelf = store.newShelf(shelfName, 1); assertNotNull("No shelf: " + shelfName, store.getShelf(shelfName)); } }; runInParallelThreads(numberOfShelves, createShelfTask); } }

39. public class Storehouse { private Map<String, Shelf> shelves = new

    HashMap<String, Shelf>(); public Shelf newShelf(String name, int capacity) { Shelf newShelf = new Shelf(capacity); shelves.put(name, newShelf); return newShelf; } public Shelf getShelf(String name) { return shelves.get(name); } } "No shelf: n28"

40. import java.util.concurrent.ConcurrentHashMap; public class Storehouse... private final Map<String, Shelf> shelves

    = new ConcurrentHashMap<String, Shelf>(); ok

41. public class Shelf... public synchronized int getCapacity() { return capacity;

    } public synchronized List<Product> getProducts() { return products; } public synchronized boolean isEmpty() { return products.isEmpty(); } public synchronized boolean isFull() { return products.size() == capacity; } public synchronized void putIn(Product product) { if (isFull()) throw new StorageException("shelf is full."); products.add(product); } public synchronized boolean takeOut(Product aBook) { return products.remove(aBook); }

42. public class Storehouse... public boolean move( Product product, String from,

    String to ) { if (!shelves.get(from).takeOut(product)) { return false; } try { shelves.get(to).putIn(product); return true; } catch (StorageException se) { shelves.get(from).putIn(product); return false; } ( public synchronized boolean move(

43. public class Storehouse... public boolean move(Product product, String from, String

    to) { Shelf source = shelves.get(from); Shelf target = shelves.get(to); synchronized (source) { synchronized (target) { return doMove(product, source, target); } } } private boolean doMove(Product product, Shelf src, Shelf trg) { ... } // Thread A: storehouse.move(aBook, "shelf a", "shelf b"); // Thread B: storehouse.move(anIPod, "shelf b", "shelf a"); (

44. public class Storehouse... public boolean move(Product product, String from, String

    to) { Shelf source = shelves.get(from); Shelf target = shelves.get(to); Object[] locks = new Object[] { source, target }; Arrays.sort(locks); synchronized (locks[0]) { synchronized (locks[1]) { return doMove(product, source, target); } } } public class Shelf implements Comparable<Shelf>... public int compareTo(Shelf other) { return System.identityHashCode(this) - System.identityHashCode(other); }

45. Für normal sterbliche Entwickler liegt die Erstellung korrekter Multi-Thread- Programme

    außerhalb ihrer Fähigkeiten

46. Nicht-erwähnte Probleme • Safe Publication, Java Memory Model • Cache

    Lines, False Sharing • Symmetric / Asymmetric Memory • Blocking Locks vs. Spin Locks vs. Non- blocking Synchronization • Fair vs Unfair Locking • Live Locks / Starvation • etc etc etc etc

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

48. Zugrundeliegende Programmiermodell Shared mutable state (aka objects) is accessed in

    multiple concurrent threads, and we use locks to synchronize / sequentialize access to the state

49. 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 das Prinzip der Kapselung ‣ Verletzt das Prinzip der Modularisierung

50. Können uns andere Programmierparadigmen retten?

51. Alternative Paradigmen • Immutability • Transactional Memory • Actors •

    Agents • Fork/Join • Map / Filter / Reduce • Dataflow Concurrency

52. Immutability to rescue? • Ohne veränderlichen Zustand, müssen Veränderungen auch

    nicht synchronisiert werden • Eine verändernde Operation gibt ein neues Objekt zurück

53. Unveränderliches Java-Objekt public class ImmutableName { private final String first,

    last; public ImmutableName(String first, String last) { this.first = first; this.last = last; } public String getFirst() { return first; } public String getLast() { return last; } @Override public int hashCode() { final int prime = 31; ... return result; } @Override public boolean equals(Object obj) { if (this == obj) ... return true; } @Override public String toString() { return ...; } }

54. Unveränderliches Groovy-Objekt @Immutable class ImmutableName { String first String last

    } ImmutableName setLast(newLast) { new ImmutableName(first, newLast) } }

55. Was passiert mit dem Zustand? • Trick: Wir unterscheiden zwischen

    Identität eines Objekts und seinem aktuellen Zustand ‣ Zustand repräsentiert durch Immutable Values ‣ Objekt bietet eine sichere Methode an, um Zustand zu aktualisieren • Der überwiegende Teil des Programms arbeitet mit "thread-sicheren" Immutables

56. @Immutable class Shelf... int capacity List products Shelf putIn(Product product)

    { if (isFull()) throw new StorageException("shelf is full.") return cloneWith(products: new ArrayList(products) << product) } Shelf takeOut(Product product) { if (!products.contains(product)) return this return cloneWith(products: new ArrayList(products).minus(product)) } private Shelf cloneWith(changes) { def newProps = ... return new Shelf(newProps) }

57. @Immutable class Shelf... long version Shelf incrementVersion() { cloneWith(version: version

    + 1) }

58. class Storehouse... final shelves = [:] as ConcurrentHashMap Shelf newShelf(String

    name, int size) { def newShelf = new Shelf(size, [], 0) shelves[name] = newShelf return newShelf } Shelf getAt(String name) { return shelves[name] } synchronized boolean update(Map shelvesToUpdate) { if (shelvesToUpdate.any {name, shelf -> shelves[name].version != shelf.version }) return false shelvesToUpdate.each {name, shelf -> shelves[name] = shelf.incVersion() } return true }

59. class Storehouse... boolean move(Product product, String from, String to) {

    while(true) { Shelf shelfTo = shelves[to] Shelf shelfFrom = shelves[from] if (shelfTo.isFull()) return false def newShelfFrom = shelfFrom.takeOut(product) if (shelfFrom == newShelfFrom) return false shelfTo = shelfTo.putIn(product) def updates = [(from): newShelfFrom, (to): shelfTo] if (update(updates)) return true } }

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

61. It‘s the coordination, stupid! Paradigma Koordination Immutability No coordination Fork/Join

    Map/Reduce Working on collections with fixed coordination Locking, Actors Explicit coordination Agent, STM Delegated coordination Dataflow Implicit coordination (c) Dierk König: Groovy in Action, 2nd ed, ch. 17

62. Transactional Memory • Heap als transaktionale Datenmenge • Transaktionseigenschaften ähnlich

    wie bei einer Datenbank (ACID) • Optimistische Transaktionen ‣ Transaktionen werden bei einer Kollision automatisch wiederholt • Transaktionen können geschachtelt werden ✘

63. public class Shelf... void putIn(Product product) { atomic { if

    (isFull()) throw new StorageException("...") products << product } } boolean takeOut(Product product) { atomic { return products.remove(product); } } public class Storehouse... boolean move(Bank bank) { atomic { if (!shelves[to].isFull() && shelves[from].takeOut(product)) { shelves[to].putIn(product) return true } return false } }

64. • Wir können weiterhin in "shared state" und Transaktionen denken

    • Die korrekte Verwendung ist wesentlich einfacher als bei Locks: Deadlocks sind ausgeschlossen! • Wir gewinnen die Komponierbarkeit von Objekten zurück Vorteile von TM

65. • Keinerlei Hilfe, wie wir unser sequenzielles Programm parallelisieren. •

    Der Fortschritt ist nicht garantiert. Livelocks sind möglich. • Ein Programm mit Transaktionen bleibt nicht deterministisch. • Keine Seiteneffekte in Transaktion erlaubt • Die performante und semantisch intuitive Implementierung ist noch Forschungsthema. Nachteile von TM

66. • Hardware Transactional Memory • Software Transactional Memory ‣ Clojure:

    Programmiersprache auf der JVM, die STM eingebaut hat ‣ Java-STM-Frameworks: Akka, Deuce, Multiverse, Gpars TM-Implementierungen

67. STM in Clojure • Nur explizit gekennzeichneter State (References) wird

    in Transaktion mit einbezogen • Alle anderen Daten / Objekte sind immutable

68. Clojure-Beispiel: Shelf (defn empty-shelf [capacity] {:products '() :capacity capacity}) (defn

    put-in [shelf product] (if (= (count (shelf :products )) (shelf :capacity )) (throw (Exception. "Shelf is full.")) (assoc shelf :products (conj (shelf :products ) product)))) (defn take-out [shelf product] (assoc shelf :products (remove #(= % product) (shelf :products ))))

69. Clojure-Beispiel: Storehouse (defn empty-storehouse [] (ref {})) (defn add-shelf [map

    name shelf] (assoc map name shelf)) (defn replace-shelf [map name shelf] (add-shelf map name shelf)) (defn new-shelf [store name capacity] (dosync (alter store add-shelf name (empty-shelf capacity)))) (defn update-shelf [store shelf-map] (dosync ...)) (defn put-in-shelf [store shelf-name product] (dosync ...)) (defn take-from-shelf [store shelf-name product] (dosync ...)) (defn move [store product from-name to-name] (dosync (put-in-shelf store to-name product) (take-from-shelf store from-name product)))

70. class Storehouse... boolean move(Product product, String from, String to) {

    while(true) { Shelf shelfTo = shelves[to] Shelf shelfFrom = shelves[from] if (shelfTo.isFull()) return false def newShelfFrom = shelfFrom.takeOut(product) if (shelfFrom == newShelfFrom) return false shelfTo = shelfTo.putIn(product) def updates = [(from): newShelfFrom, (to): shelfTo] if (update(updates)) return true } }

71. Wo loggen wir erfolgreiche Transaktionen?

72. Fixed Coordination: Parallele Collections • Wir arbeiten auf allen Elementen

    einer Collection gleichzeitig • Voraussetzung: Die Einzeloperationen sind unabhängig voneinander • Typische parallele Aktionen: ‣ Transformieren ‣ Filtern ‣ Zusammenfassen (reduce)

73. Fork/Join on collections import static groovyx.gpars.GParsPool.withPool def numbers = [1,

    2, 3, 4, 5, 6] withPool { assert 91 == numbers .collectParallel { it * it } .sumParallel() }

74. More such methods any { ... } collect { ...

    } count(filter) each { ... } eachWithIndex { ... } every { ... } find { ... } findAll { ... } findAny { ... } fold { ... } fold(seed) { ... } grep(filter) groupBy { ... } max { ... } max() min { ... } min() split { ... } sum()

75. Map/Filter/Reduce on collections import static groovyx.gpars.GParsPool.withPool withPool { assert 84

    == [0, 1, 2, 3, 4, 5, 6].parallel .filter { it % 2 == 0 } .map { it + 1 } .map { it ** 2 } .reduce { a, b -> a + b } }

76. Fork/Join vs Map/Filter/Reduce ! fixed coordination (c) Dierk König

77. Explicit Coordination: 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

78. Aktoren in GPars import static groovyx.gpars.actor.Actors.* def printer = reactor

    { println it } def decryptor = reactor { reply it.reverse() } actor { decryptor << 'lellarap si yvoorG' react { answer -> printer << 'Decrypted message: ' + answer decryptor.stop() printer.stop() } }.join() (c) Dierk König

79. Actors - Vorteile • Unabhängige Aktoren • Skalierbar • Verteilbar

    • Leichtere Vermeidung von ‣ Race Conditions ‣ Dead Locks ‣ Starvation

80. Actors - Nachteile • Explizite Koordination notwendig! • Kommunikation über

    asynchrone Nachrichten ist für viele Problemstellungen eine Komplizierung • Nicht geeignet für Probleme, die einen echten Konsens über gemeinsame Objekte erfordern

81. Aktoren in Erlang • Aktoren: Prozesse + Modul • Selektiver

    Nachrichtenempfang • "Warten auf Nachrichten" als Continuation • Endrekursive Funktionen zur Zustands

82. loop(KeyValues) -> receive {key, Sender, Key} -> receive {value, Sender,

    Value} -> NewElement = {Key, Value}, loop([NewElement | KeyValues]) end; {get, Sender, Key} -> reply(Sender, getValue(KeyValues, Key)), loop(KeyValues); stop -> ok end. reply(Sender, ReplyMsg) -> Sender ! {self(), ReplyMsg}. getValue(..,..) -> ...

83. Erlang Process Patterns • Process should encapsulate an activity, not

    a task • Archetypes of processes ‣ Client / Server ‣ Finite State Machine ‣ Event Manager / Event Handler • Supervisor hierarchies for robustness and fault tolerance

84. JVM-Probleme für nebenläufiges Programmieren • Kurz- und mittelfristig ‣ keine

    Closures ‣ keine nativen persistenten Datenstrukturen ‣ die meisten Java-Bibliotheken nicht thread-sicher • Langfristig ‣ Keine Unterstützung von Coroutines/Continuations ‣ Late binding verhindert Sicherheit ‣ Task-basierte Concurrency skaliert nicht gut ‣ Keine performante Kommunikation zwischen Tasks ‣ Keine Optimierung für End-Rekursion

85. Delegate to an Agent import groovyx.gpars.agent.Agent def safe = new

    Agent<Storehouse>( storehouse ) safe << { move ... } println safe.val

86. Agents • Sie kapseln nicht threadsichere (Java-) Komponenten • Konzeptionell

    ähnlich wie Agents in Clojure • Implementierung unterscheiden sich stark in Effizienz

87. DataFlow for implicit coordination import groovyx.gpars.dataflow.DataFlowVaraiable import static groovyx.gpars.dataflow.DataFlow.task final

    dichte = new DataflowVariable() final gewicht = new DataflowVariable() final volumen = new DataflowVariable() task { dichte << gewicht.val / volumen.val } task { gewicht << 10.6 } task { volumen << 5.0 } assert dichte.val == 2.12

88. DataFlow • Write-Once, Read-Many (non-blocking) • Flavors: variables, streams, operators,

    tasks, flows • Model the flow of data, not the control flow!

89. Dataflow-Operators final leftAddend = new DataflowQueue() final rightAddend = new

    DataflowQueue() final sum = new DataflowQueue() operator(inputs: [leftAddend, rightAddend], outputs: [sum], { left, right -> sum << left + right }) task { [10, 20, 30].each { leftAddend << it } } task { [100, 200, 300].each { rightAddend << it } } [110, 220, 330].each { assert it == sum.val }

90. 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 • Skalieren gut

91. 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 • Andere JVM-Implementierungen ‣ Scala Dataflow (akka), FlowJava (akademisch & tot)

92. Takeaways • Shared mutable state ist böse • Andere Paradigmen

    sind einfacher zu verstehen, erfordern aber häufig ein Umdenken bei Design / Architektur • Java als Sprache hat zu viel Zeremonie, um alternative Ansätze knapp und lesbar schreiben zu können ‣ Groovy / Gpars sehr gut zum Experimentieren • JVM als Plattform ist für manche Ansätze nicht optimal geeignet
93. None

94. Links Code-Beispiele https://github.com/jlink/ ConcurrencyOnJvmAndElsewhere Hinweise http://jax.de http://www.parallel2012.de Sonderheft iX Multicore

    (Dez. 2011) Zum Ausprobieren http://gpars.codehaus.org/ http://clojure.org/ http://www.erlang.org