Understanding Concurrency Basics for Optimal Performance

1. http://flic.kr/p/fMVpEu Thread Synchronization

2. So why would you want concurrency anyway? http://flic.kr/p/9ksxQa

3. public class MySequentialServer { … public static void main(String[] args) { for (;;) { Connection conn = socket.accept(); service(conn); } } } Why is this sequential design lame?How might concurrency improve it? http://flic.kr/p/9ksxQa

4. So why would you want concurrency anyway? Performance. Performance. Performance. Increase responsiveness. Do more work in less time. Increase throughput. http://flic.kr/p/9ksxQa

5. Buffer put(c : Connection)get() : Connection Here’s one possible concurrent server design 1 Listener 1..* Handler buf data : Connection[] buf 1 1 for (;;) { buf.put(socket.accept());} for (;;) { service(buf.get());} See any problems with it?

6. Shared passive object Active objects Error!

7. Initially, there is oneconnection c in the buffer H1 executes first Error!

8. Error!

9. Error!

10. H1 removes the connectionfrom the buffer Error!

11. H2 tries to pull froman empty buffer Error!

12. Buffer put(c : Connection)get() : Connection So race conditions in the bufferare a problem with this design 1..* Handler 1 Listener buf 1 buf data : Connection[] 1 for (;;) { service(buf.get());} for (;;) { buf.put(socket.accept());}

13. How do we preventrace conditions? Answer: Synchronization! Java provides two basic mechanisms: • Mutex locks • For enforcing mutually exclusive access to shared data • Condition variables • For enabling threads to wait for application-specific conditions to become true http://flic.kr/p/aGcqRp

14. Mutex locks • States: • unlocked • locked by exactly 1 thread • Operations: • lock() (aka acquire) • unlock() (aka release) • Operations are atomic • Threads that call lock() on a held lock must wait http://flic.kr/p/678N6L

15. Mutex locks class X { private final ReentrantLockmutex = new ReentrantLock(); // ... public void m() { mutex.lock(); try { // ... method body ... } finally { mutex.unlock() } } } http://flic.kr/p/678N6L

16. Lock not held(no waiters) Lock held by T1(still no waiters)

17. T2 waits on lock T1 releases andT2 becomes holder

18. In Java, every object has an intrinsic lock(inherited from class Object)Java provides a synchronized keyword for doing implicit acquires/releases class X { public synchronized void m() { // ... method body ... } } Can you fix our server example now?

19. Handling a full/empty buffer is still a problem What we’d like to happen is • Listener to wait while the buf is full • Handlers to wait while the buf is empty Condition variables to the rescue!

20. Condition variables • Object for enabling waiting for some condition • Always associated with a particular mutex • Mutex must be held while invoking operations • Operations • await() (aka wait) • signal() (aka notify) • signalAll() (aka notifyAll; aka broadcast)

21. Condition variables class Buffer { final Lock lock = new ReentrantLock(); final ConditionnotFull = lock.newCondition(); // ... public void put(Object x) throws ... { lock.lock(); try { while (isFull()) { notFull.await(); } // ... do the put ... notEmpty.signal(); } finally { lock.unlock(); } } }

22. Objects also have intrinsic condition variables class Buffer { public synchronized void put(Object x) { while (isEmpty()) { wait(); } // ... do the put ... notify(); } }

23. T1 holds the lock No waiters

24. Note: T1 still in the call to wait

26. What you’ve just seen is theMonitor Pattern • Monitor object: An object whose methods are executed in mutual exclusion http://flic.kr/p/7ZkGEH