1. Thread Synchronization
Thread Synchronization

2. So why would you want concurrency anyway?

3. 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?

4. So why would you want concurrency anyway?
Performance.
Increase responsiveness.
Do more work in less time.
Increase throughput.

5. Here’s one possible concurrent server design1
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?

6. Active objects
Shared passive object
Error!

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

8. Error!

9. Error!

10. H1 removes the connection from the buffer
Error!

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

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

13. 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

14. 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

15. Mutex locks
class X {
private final ReentrantLock mutex = new ReentrantLock();
// ...
public void m() {
mutex.lock();
try {
// ... method body ...
} finally {
mutex.unlock() }

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

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

18. 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?

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

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 the Monitor Pattern
Monitor object: An object whose methods are executed in mutual exclusion