Principles of Software Construction:

Objects, Design, and Concurrency

Part 3: Concurrency

Introduction to concurrency

Josh Bloch Charlie Garrod

17-214 1
Administrivia

• Homework 5 team sign-up deadline tomorrow at 5 p.m. EDT

• Midterm exam tomorrow/Thursday (4/7-8)
– Practice exam is out
– Exam review session tonight 7-9 p.m.
– Exam released Wednesday night, due Thursday 11:59 p.m.

17-214 2
Today’s lecture: concurrency motivation and primitives

• Why concurrency?
– Motivation, goals, problems, …
• Concurrency primitives in Java
• Coming soon (not today):
– Higher-level abstractions for concurrency
– Program structure for concurrency
– Frameworks for concurrent computation

17-214 6
Moore’s Law (1965) – number of transistors on a chip
doubles every two years

17-214 7
CPU Performance and Power Consumption

• Dennard Scaling (1974) – each time you double transistor density:

– Speed (frequency) goes up by about 40% (Why 40%?)…
– While power consumption of the chip stays constant (proportional to area)
• Combined w/ Moore’s law, every 4 years the number of transistors
quadruples, speed doubles, and power consumption stays constant
• It was great while it lasted…
– Started breaking down in the mid ’90s and broke down completely in the
mid ’90s due to leakage currents ☹️
– More power is required at higher frequency, generating more heat
– And there’s a limit to how much heat a chip can tolerate

17-214 8
One option: fix the symptom

• Dissipate the heat

17-214 9
One option: fix the symptom

• Better(?): Dissipate the heat with liquid nitrogen

17-214 10
17-214 11
Concurrency then and now

• In the past, multi-threading just a convenient abstraction

– GUI design: event dispatch thread
– Server design: isolate each client's work
– Workflow design: isolate producers and consumers
• Now: required for scalability and performance

17-214 12
We are all concurrent programmers

• Java is inherently multithreaded

• To utilize modern processors, we must write multithreaded code
• Good news: a lot of it is written for you
– Excellent libraries exist (e.g., java.util.concurrent)
• Bad news: you still must understand fundamentals
– …to use libraries effectively
– …to debug programs that make use of them

17-214 13
Aside: Concurrency vs. parallelism, visualized

• Concurrency without parallelism:

Thread1
Thread2
Thread3

• Concurrency with parallelism:

Thread1
Thread2
Thread3

17-214 14
Basic concurrency in Java
Review

• An interface representing a task

public interface Runnable {
void run();
}

• A class to execute a task in a CPU thread

public class Thread {
public Thread(Runnable task);
public void start();
public void join();
…
}

17-214 15
Example: Money-grab (1/2)

public class BankAccount {

private long balance;
public BankAccount(long balance) {
this.balance = balance;
}

static void transferFrom(BankAccount source,

BankAccount dest, long amount) {
source.balance -= amount;
dest.balance += amount;
}

public long balance() {

return balance;
}
}

17-214 16
Example: Money-grab (2/2)
What would you expect this program to print?

public static void main(String[] args) throws InterruptedException {

BankAccount bugs = new BankAccount(100);
BankAccount daffy = new BankAccount(100);

Thread bugsThread = new Thread(()-> {

for (int i = 0; i < 1_000_000; i++)
transferFrom(daffy, bugs, 100);
});

Thread daffyThread = new Thread(()-> {

for (int i = 0; i < 1_000_000; i++)
transferFrom(bugs, daffy, 100);
});

bugsThread.start(); daffyThread.start();
bugsThread.join(); daffyThread.join();
System.out.println(bugs.balance() + daffy.balance());
}

17-214 17
What went wrong?

• Daffy & Bugs threads had a race condition for shared data
– Transfers did not happen in sequence
• Reads and writes interleaved randomly
– Random results ensued

17-214 18
The challenge of concurrency control

• Not enough concurrency control: safety failure

– Incorrect computation
• Too much concurrency control: liveness failure
– Possibly no computation at all (deadlock or livelock)

17-214 19
Shared mutable state requires concurrency control

• Three basic choices:

1. Don't share: isolate state in individual threads
2. Don't mutate: share only immutable state
3. If you must share mutable state: synchronize to achieve safety

17-214 20
An easy fix for our BankAccount program:

public class BankAccount {

private long balance;
public BankAccount(long balance) {
this.balance = balance;
}
static synchronized void transferFrom(BankAccount source,
BankAccount dest, long amount) {
source.balance -= amount;
dest.balance += amount;
}
public long balance() {
return balance;
}
}

17-214 21
Concurrency control with Java’s intrinsic locks
with an explicit lock

• synchronized (lock) { … }
– Synchronizes entire block on object lock; cannot forget to unlock
– Intrinsic locks are exclusive: One thread at a time holds the lock
– Intrinsic locks are reentrant: A thread can repeatedly get same lock

Thread1
Thread2
Thread3

17-214 22
Concurrency control with Java’s intrinsic locks
with an implicit lock

• synchronized (lock) { … }
– Synchronizes entire block on object lock; cannot forget to unlock
– Intrinsic locks are exclusive: One thread at a time holds the lock
– Intrinsic locks are reentrant: A thread can repeatedly get same lock
• synchronized on an instance method
– Equivalent to synchronized (this) { … } for entire method
• synchronized on a static method in class Foo
– Equivalent to synchronized (Foo.class) { … } for entire method

17-214 23
Another example: serial number generation
What would you expect this program to print?

public class SerialNumber {

private static long nextSerialNumber = 0;
public static long generateSerialNumber() {
return nextSerialNumber++;
}
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[5];
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 1_000_000; j++)
generateSerialNumber();
});
threads[i].start();
}
for(Thread thread : threads)
thread.join();
System.out.println(generateSerialNumber());
}
}

17-214 24
What went wrong?

• An action is atomic if it is indivisible

– Effectively, it happens all at once
• No effects of the action are visible until it is complete
• No other actions have an effect during the action
• Java’s ++ (increment) operator is not atomic!
– It reads a field, increments value, and writes it back
• If multiple calls to generateSerialNumber see the same
value, they generate duplicates

17-214 25
Again, the fix is easy

public class SerialNumber {

private static long nextSerialNumber = 0;
public static synchronized long generateSerialNumber() {
return nextSerialNumber++;
}
public static void main(String[] args) throws InterruptedException {
Thread[] threads = new Thread[5];
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 1_000_000; j++)
generateSerialNumber();
});
threads[i].start();
}
for(Thread thread : threads)
thread.join();
System.out.println(generateSerialNumber());
}
}

17-214 26
But you can do better!
java.util.concurrent is your friend

public class SerialNumber {

private static final AtomicLong nextSerialNumber = new AtomicLong();
public static long generateSerialNumber() {
return nextSerialNumber.getAndIncrement();
}

public static void main(String[] args) throws InterruptedException{

Thread[] threads = new Thread[5];
for (int i = 0; i < threads.length; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 1_000_000; j++)
generateSerialNumber();
});
threads[i].start();
}
for(Thread thread : threads) thread.join();
System.out.println(generateSerialNumber());
}
}

17-214 27
Some actions are atomic
Precondition: Thread A: Thread B:
int i = 7; i = 42; ans = i;

• What are the possible values for ans?

17-214 28
Some actions are atomic
Precondition: Thread A: Thread B:
int i = 7; i = 42; ans = i;
• What are the possible values for ans?

i: 00000…00000111

…
i: 00000…00101010

ans: 00000…00101111

17-214 29
Some actions are atomic
Precondition: Thread A: Thread B:
int i = 7; i = 42; ans = i;
• What are the possible values for ans?

i: 00000…00000111

…
i: 00000…00101010

• In Java:
– Reading an int variable is atomic
– Writing an int variable is atomic

– Thankfully, ans: 00000…00101111 is not possible

17-214 30
 Bad news: some simple actions are not atomic

• Consider a single 64-bit long value

high 32 bits low 32 bits

– Concurrently:
• Thread A writing high and low bits
• Thread B reading high and low bits
Precondition: Thread A: Thread B:
long i = 10_000_000_000; i = 42; ans = i;

ans: 01001…00000000 (10,000,000,000)

All are
ans: 00000…00101010 (42) possible!

ans: 01001…00101010 (10,000,000,042)

17-214 31
Yet another example: cooperative thread termination
How long would you expect this program to run?

public class StopThread {

private static boolean stopRequested;

public static void main(String[] args) throws Exception {

Thread backgroundThread = new Thread(() -> {
while (!stopRequested)
/* Do something */ ;
});
backgroundThread.start();

TimeUnit.SECONDS.sleep(5);
stopRequested = true;
}
}

17-214 32
What went wrong?

• In the absence of synchronization, there is no guarantee as to

when, if ever, one thread will see changes made by another
• JVMs can and do perform this optimization (“hoisting”):
while (!done)
/* do something */ ;
becomes:
if (!done)
while (true)
/* do something */ ;

17-214 33
Why is synchronization required for communication
among threads?
• Naively: Process
– Thread state shared in memory Thread Thread

Memory
• A (slightly) more accurate view:
– Separate state stored in registers and caches, even if shared

Process
Thread Thread
Cache Cache

Memory
17-214 34
How do you fix it?

public class StopThread {

private static boolean stopRequested;
private static synchronized void requestStop() {
stopRequested = true;
}
private static synchronized boolean stopRequested() {
return stopRequested;
}
public static void main(String[] args) throws Exception {
Thread backgroundThread = new Thread(() -> {
while (!stopRequested())
/* Do something */ ;
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(5);
requestStop();
}
}
17-214 35
A better(?) solution
volatile is synchronization without mutual exclusion

public class StopThread {

private static volatile boolean stopRequested;

public static void main(String[] args) throws Exception {

Thread backgroundThread = new Thread(() -> {
while (!stopRequested)
/* Do something */ ;
});
backgroundThread.start();

TimeUnit.SECONDS.sleep(5);
stopRequested = true;
}
}

17-214 36
Summary

• Like it or not, you’re a concurrent programmer

• Ideally, avoid shared mutable state
– If you can’t avoid it, synchronize properly
• Some things that look atomic aren’t (e.g., val++)
• Even atomic operations require synchronization
– e.g., stopRequested = true
– Synchronization is required for communication as well as mutual exclusion

17-214 37