1. PROGRAMMING FOR
CONCURRENCY
In Java

2. WOZU?
CPUs haben mehrere Kerne
m2b Server: 8 virtuelle
Dualcores in kommenden
mobilen Geräten
Rechenleistung nutzbar machen
vgl. Kaffee kochen

3. OPTIMIERUNGEN
Warnung: „The root of all evil“ (Donald Knuth)
Multiprocessing bringt neue Komplexitätsdimension
Bugtracking wird sehr sehr schwer
Vorher korrekter Code kann nun fehlerhaft sein
Performance kann schlechter werden (synchronisieren)
Deswegen: Notwendigkeit durch Profiling „beweisen“

4. GUTE NACHRICHT
Multiprocessing wird uns geschenkt in
Application Server (pro Request)
Multi-Prozess Umgebung (Tomcat, MySQL, ...)
Libraries (nicht unser Problem)
High Level Programmierung (Garbage Collector, JIT)
Und einfacher gemacht durch
Gute Frameworks (GCD, OpenCL, ...)

5. DREI VARIANTEN
Single threaded
Dual threaded
UI mit Worker
Massiv parallel
Große Datenmengen
Grafikverarbeitung, AI, Data Mining

6. BUILDING BLOCKS
Prozesse
besitzt eigenen privaten Speicherbereich (!)
Ein Programm ist meist genau ein Prozess
Threads
gehören zu einem Prozess
mehrere Threads teilen sich Speicher

7. EINFACHES BEISPIEL
Java Class: Thread
run() und start()
Java Interface: Runnable
kann an Thread übergeben
werden

8. PARALLELE FEHLER
Thread Interference
bislang korrekter Code wird fehlerhaft
Memory Consistency
Annahmen über Speicherzustände stimmen nicht mehr
(Deadlocks)
Threads blockieren sich gegenseitig

9. SYNCHRONIZE
Entwickler ist für Synchronisierung
verantwortlich
Designfehler
synchronized heißt: nur ein Thread
synchronized(Object)
Parallele Performance

10. KOMPLEXITÄT++
Optimales Locking
Mehr Parallelität
komplexer
volatile
atomic read/write
nicht ausreichend

13. HILFEN
Zustandsraum klein
halten
Immutable Objects
keine korrupten Zustände

14. HILFEN
Kontrollierbare Anzahl Threads
Thread Pool / Worker / Jobs
Webserver Prinzip
java.util.concurrent.Executors
java.util.concurrent.ThreadPoolExecutor

15. CALLABLE
Pool mit 3 Threads
Callable als kleiner Job
Future<Integer>
Immutable

16. SUCCESS STORY
MapReduce
funktionale
Denkweise
parallelisierung ist
unabhängig

17. SUCCESS STORY 2
Grafikberechnungen
800 SPUs (Radeon HD 4850)
Cuda & OpenCL
Rechenkernel
Große Datenmengen
> 1 TFLOP/s

18. FAZIT
Regeln zur Optimierung gelten
Zustandsraum klein halten (Immutable)
An erfolgreichen Architekturen orientieren
Single-Thread Optimierungen haben Vorrang
Java -> C vs. Single -> Multicore
|CPUs| ist Maximum