A lightning talk from a geeknight at Polopoly in 2009 about concurrent programming in Java.

2. Notes on Concurrent, parallel programming with threads Concurrent = work done in several computational processes, only requires one CPU Parallel = work (computations) done simultaneous, requires multiple CPU:s – locally or distributed

3. GC and Threads and Java CG made easy in Java Person p = null; Concurrent programming made possible (but not easy) Low level support: threads and mutexes volatile boolean stop = false; public void stop() { stop = true; } public void run() { while(!stop) { try { // Do some work Thread.sleep(10); // check stop }catch(InterruptedException ie) { // Ignore } } } // stop = true; thread.interrupt();

4. Some Hard stuff Data visibility between threads Volitile semantics Asynchronous code Race conditions and Deadlocks Congestion/Performance

5. Data visibility Data not guaranteed to be visable between threads without synchronization long and double not even guaranteed to be ”complete” // In thread 1 at time 1 commonObject.myLong = Long.MAX_VALUE; // In thread 2 at time 2 if(commonObject.myLong > Integer.MAX_VALUE) {

7. If one thread can see an object another thread constructs it might see broken objects (ref available before object constructed)

8. Double locking // Broken multithreaded version // "Double-Checked Locking" idiom class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) synchronized(this) { if (helper == null) helper = new Helper(); } return helper; } // other functions and members... }

10. Sending asynchronous messages is complex public void fetchAsync() { Thread t = new Thread(new Runnable() { public void run() { // Do work in other thread dataArived("hello"); } }); t.start(); } public synchronized void dataArived(String s) { // Update data, must be synchronized somehow to be visable }

12. Amdahl's law (simlified): 1/(1 – p)

13. where P is percentage parallelizable work gives the maximum number of CPU:s that are meaningfull to use when speed is considered.

14. For example, of 5 percent of the application is serialized because of a common synchronization (such as read on a cache), the maximum number of CPU:s are 20

15. To fully gain througout by 64 cores about 99 % must be parallelizable

16. Polopoly on multi core machines

18. Lock striping

19. Optimized for reads: does not block reads even when its updated

20. Does often not block on updates either

21. Weakly consistent iterators

22. Atomic check and take action methods V putIfAbsent(K key, V value); boolean remove(Object key, Object value); V replace(K key, V value); boolean replace(K key, V oldValue, V newValue);

24. Provides management methods

25. May track submitted task and get result back

26. Uses Future and Callable Callable<String> worker = new Callable<String>() { int c = 0; public String call() { try {Thread.sleep(2000L);}catch(Exception ignore){} return &quot;jobb no &quot; + c++; } }; ExecutorService exe = Executors.newSingleThreadExecutor(); Future<String> result = exe.submit(worker); while(!result.isDone()) { // Do something other } String s = result.get();

28. volatile but with conditional atomicity

29. Finer granularity of locking (hardware based)

30. Non blocking

31. Built on optimistic assumptions: do it, check and redo

32. Non blocking counting AtomicLong at = new AtomicLong(); // one thread, no synchronzied long current = at.get(); // another thread increment, no sync at.incrementAndGet();

34. Identity (holder of values over time)

35. State (value of an identity at a point of time)

36. Time (ordering)

37. PDS

38. Clojure Clojure Transaction re-ref (coordinated) Asynchronous Atomic and independent

40. Memory Conflict Detection

41. Eventually Consistent

42. Imutable