Concurrency Basics for Optimal Performance

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

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

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. Performance. Performance. Increase responsiveness. Do more work in less time. Increase throughput. http://flic.kr/p/9ksxQa

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?

Shared passive object Active objects Error!

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

Error!

H1 removes the connectionfrom the buffer Error!

H2 tries to pull froman empty buffer Error!

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

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

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

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

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

T2 waits on lock T1 releases andT2 becomes holder

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 ConditionnotFull = 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 theMonitor Pattern • Monitor object: An object whose methods are executed in mutual exclusion http://flic.kr/p/7ZkGEH

Concurrency Basics for Optimal Performance

Télécharger la présentation

Plus de contenu associé