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

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

Why is this sequential design lame? How might concurrency improve it? 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

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

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

Active objects Shared passive object Error!

Initially, there is one connection c in the buffer H1 executes first Initially, there is one connection c in the buffer Error!

Error!

Error!

H1 removes the connection from the buffer Error!

H2 tries to pull from an empty buffer Error! H2 tries to pull from an empty buffer

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

How do we prevent race 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

Mutex locks States: Operations: Operations are atomic 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

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

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

T1 releases and T2 becomes holder T2 waits on lock T1 releases and T2 becomes holder

Can you fix our server example now? 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?

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!

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)

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

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

T1 holds the lock No waiters

Note: T1 still in the call to wait

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