Java 5

Notes• Threads inherit their priority and daemon

properties from their creating threads

• The method thread.join() blocks and waits

until the thread completes running

• A thread can have a name for identification

• Stopping a running thread was possible in

old versions of Java, but it is now deprecated

• Instead, interruption mechanisms should be

used (thread.interrupt())

2

Notes

• isInterupted() – can be used by a thread to check if

another thread has been interrupted

• isAlive() – can be used by a thread to check if

another thread is alive

• join() – allows one thread to wait for the completion

of another

3

• Monitors are key elements in Java's

thread synchronization

• Every object has a monitor

• An object's monitor is used as a

guardian that watches a block of code

(called a critical section) and enables

only one thread to enter that code

• To enter a critical section, a thread

must first acquire an ownership over

the corresponding monitor

Synchronization

4

• Only one thread can own a specific

monitor

• If a thread A tries to enter a block under a monitor and a different thread B has already entered that block, A will wait until B releases the monitor and (hopefully) that monitor will be passed to A

– Hence, monitors are related to as locks

• When a thread leaves the critical

section, the monitor is automatically

released

• Threads awaiting a monitor are blocked

and queued

Synchronization

5

6

public class SynchronizedCounter {

private int c = 0;

public synchronized void increment() { c++; }

public synchronized void decrement() { c--; }

public synchronized int value() { return c; }

}

Synchronization

Example 1 – synchronizing methods:

The synchronized keyword on a method means that if this is

already locked anywhere

(on this method or elsewhere) by another thread,

we need to wait till this is unlocked before entering the method

7

public void addName(String name) {

synchronized(this) {

lastName = name;

nameCount++;

}

nameList.add(name);

}

Synchronization

Example 2 – synchronizing blocks:

When synchronizing a block, key for the locking should be

supplied (usually would be this)

The advantage of not synchronizing the entire method is efficiency

8

public class TwoCounters {

private long c1 = 0, c2 = 0;

private Object lock1 = new Object();

private Object lock2 = new Object();

public void inc1() {

synchronized(lock1) {

c1++;

}

}

public void inc2() {

synchronized(lock2) {

c2++;

}

}

}

Synchronization

Example 3 – synchronizing using different locks:

You must be

absolutely sure

that there is no tie

between c1 and c2

9

public class Screen {

private static Screen theScreen;

private Screen(){…} // private c’tor

public static synchronized Screen getScreen() {

if(theScreen == null) {

theScreen = new Screen();

}

return theScreen;

}

}

Synchronization

Example 4 – synchronizing static methods:

This is a

Singleton

example

It is not the most

efficient way to implement

Singleton in Java

10

Synchronization

Example 4 – synchronizing static methods …

Having a static method be synchronized means that ALL objects of this

type are locked on the method and can get in one thread at a time.

The lock is the Class object representing this class.

The performance penalty might be sometimes too high – needs careful

attention!

11

public class Screen {

private static Screen theScreen = new Screen();

private Screen(){…} // private c’tor

public static getScreen() {

return theScreen;

}

}

Synchronization

Example 4’ – a better singleton:

No

synchronization

Cycle buffer

public class LogEntryBase {

Entry entries[];

int size; int first=0;int last=0; int current=0;

public LogEntryBase() { this(500);}

public LogEntryBase(int si)

{ size=si;entries=new Entry[size];}

synchronized public void addEntry(Entry e)

{ entries[last]=e;

last=(last+1) % size;

if (last==first) first=(first+1) % size;

if (last==current) current=(current+1) % size;

}

synchronized public Entry[] getUnread()

{ Entry ret[]; int ile=0,i,j;

if (current==last) return new Entry[0];

if (last<current) ile=size-current+last;

else ile=last-current;

ret=new Entry[ile];

for (i=0,j=current;i<ile;i++,j=(j+1)%size) ret[i]=entries[j];

current=last;return ret;

}}

13

wait(), notify(), notifyAll()

wait() and notify() allows a thread to

wait for an event

A call to notifyAll() allows all threads that are on wait() with the

same lock to be released

A call to notify() allows one arbitrary thread that is on a wait() with

the same lock to be released

Instead of

“busy wat” or

sleep loop!

wait(), notify(), notifyAll()

• Suppose that an object has some

monitor, but conditions disable it from

completing the critical section

• The wait/notify mechanism enables that

object to release the monitor and wait

until conditions are changed

14

wait()

• The method Object.wait() requires the

current thread to own the monitor of the

object

• When called, the current thread– releases ownership on the object's monitor

– stops and waits until some other thread will wake

it up and the monitor will be re-obtained

15

notify()

Like wait, requires the object to own the monitor

The method Object.notify() wakes up an arbitrary

thread that waits on the monitor of the object

Object.notifyAll() wakes all such threads

When a thread is waken up, it regularly waits for the

monitor to be available (since it called Object.wait())

The thread calling notify should release the monitor

for the waiting thread to continue (e.g exit the

synchronized scope)

16

17

public class Drop {

// Message sent from producer to consumer

private String message;

// A flag, True if consumer should wait for

// producer to send message, False if producer

// should wait for consumer to retrieve message

private boolean empty = true;

...

wait(), notify(), notifyAll()

Example

(from http://java.sun.com/docs/books/tutorial/essential/concurrency/example/Drop.java):

Flag must be used, never

count only on the notify

18

public class Drop {

...

public synchronized String take() {

// Wait until message is available

while (empty) {

// we do nothing on InterruptedException

// since the while condition is checked anyhow

try { wait(); } catch (InterruptedException e) {}

}

// Toggle status and notify on the status change

empty = true;

notifyAll();

return message;

}

...

}

wait(), notify(), notifyAll()

Example (cont’)Must be in

synchronized context

19

public class Drop {

...

public synchronized void put(String message) {

// Wait until message has been retrieved

while (!empty) {

// we do nothing on InterruptedException

// since the while condition is checked anyhow

try { wait(); } catch (InterruptedException e) {}

}

// Toggle status, store message and notify consumer

empty = false;

this.message = message;

notifyAll();

}

...

}

wait(), notify(), notifyAll()

Example (cont’)Must be in

synchronized context

Sophisticated Primitives

• Wait and Notify:

– basis for higher level constructs.

– general constructs

• Specific mechanisms make code easier to understand and demand less details when using them:

– Semaphores

– Readers-Writers locks.

20

Semaphores

• Object controls bounded number of permits(permit = train ticket):

– Threads ask semaphore for permit (a ticket).

– If semaphore has permits available, one permit is assigned to requesting thread.

– If no permit available, requesting thread is blocked until permit is available

• when a thread returns permit received earlier

21

implementation

22

Java Semaphore class properties

• not re-entrant – thread calls acquire() twice, must release() twice!

• semaphore can be released by a thread other than owner (unlike lock) – no ownership.

• constructor accepts fairness parameter – if t1 requested before t2 it will receive first

• services as tryAcquire and managing permits.

23

class Pool {

private static final int MAX_AVAILABLE = 100;

private final Semaphore available = new

Semaphore(MAX_AVAILABLE, true);

public Object getItem() throws InterruptedException {

available.acquire();

return getNextAvailableItem();

}

public void putItem(Object x) {

if (markAsUnused(x))

available.release();

}

// Not a particularly efficient data structure; just for demo

protected Object[] items = ... whatever kinds of items being

managed

protected boolean[] used = new boolean[MAX_AVAILABLE];

protected synchronized Object getNextAvailableItem() {

for (int i = 0; i < MAX_AVAILABLE; ++i) {

if (!used[i]) {

used[i] = true;

return items[i];

}

}

return null; // not reached

}

protected synchronized boolean markAsUnused(Object item) {

for (int i = 0; i < MAX_AVAILABLE; ++i) {

if (item == items[i]) {

if (used[i]) {

used[i] = false;

return true;

} else

return false;

}

}

return false;

}

What is a Thread Pool?

•A collection of threads that are created once (e.g.

when a server starts)

•That is, no need to create a new thread for every

client request

•Instead, the server uses an already prepared

thread if there is a free one, or waits until there is a

free thread

26

Why Using Thread Pools?

•Thread pools improve resource utilization

•The overhead of creating a new thread is significant

•Thread pools enable applications to

control and bound their thread usage

•Creating too many threads in one JVM can cause the system

to run out of memory and even crash

•There is a need to limit the usage of system resources such

as connections to a database

27

Thread Pools in Servers

• Thread pools are especially important in client-server applications

– The processing of each individual task is short-lived and the number of requests is large

– Servers should not spend more time and consume more system resources creating and destroying threads than processing actual user requests

• When too many requests arrive, thread pools enable the server to force clients to wait until threads are available

28

The “Obvious” Implementation

• There is a pool of threads

• Each task asks for a thread when starting and returns the thread to the pool after finishing

• When there are no available threads in the pool the thread that initiates the task waits till the pool is not empty

• What is the problem here?“Synchronized” model - the

client waits until the server

takes care of its request…

29

The “Obvious” Implementation is Problematic

• When the pool is empty, the submitting thread has to wait for a thread to be available

– We usually want to avoid blocking that thread

– A server may want to perform some actions when too many requests arrive

• Technically, Java threads that finished running cannot run again

30

Task Queue

Worker Threads

wait()

If Q is Empty

All the worker threads wait for tasks

A Possible Solution

Every thread looks for

tasks in the queue

31

Task Queue

Worker Threads

Task

The number of worker threads

is fixed. When a task is inserted

to the queue, notify is called

A Possible Solution

“A-synchronized” model:

“Launch and forget”

32

Task Queue

Worker Threads

Task

The number of worker threads

is fixed. When a task is inserted

to the queue, notify is called

A Possible Solution

notify()

33

Task Queue

Worker Threads

A Possible Solution

The task is executed by

the thread

34

Task Queue

Worker Threads

A Possible Solution

The task is executed by

the thread

The remaining tasks are

executed by the other threads

35

Task Queue

Worker Threads

A Possible Solution

When a task ends, the

thread is released

While the Q is not empty, take the task from

the Q and run it (if the Q was empty, wait()

would have been called)

36

Task Queue

Worker Threads

A Possible Solution

A new task is executed

by the released thread

37

Threads can leak

A thread can endlessly wait for an I/O operation to complete For example, the client may stop the interaction with the socket without closing it properly

What if task.run() throws a runtime exception (as opposed to other exceptions that a programmer of a client application has to catch in order to succeed compiling)?

Solutions:

Bound I/O operations by timeouts using wait(time)

Catch possible runtime exceptions

38

Risks in Using Thread Pools

Pool Size What is better: to have a large pool or a small pool? Each thread consumes resources

memory, management overhead, etc. A large pool can cause starvation

Incoming tasks wait for a free thread A small pool can cause starvation

Therefore, you have to tune the thread pool sizeaccording to the number and characterizations of expected tasks

There should also be a limit on the size of the task queue (why?)

39

Executor

• The class Executors has 2 static methods to create thread pools– ExecutorService newFixedThreadPool(int nThreads)

• Pool of a fixed size– ExecutorService newCachedThreadPool()

• Creates new threads as needed

• New threads are added to the pool, and recycled

• ExecutorService has an execute method– void execute(Runnable command)

40

The Dining Philosophers Problem

41

• Let there be one rice bowl in the center

• Let there be five philosophers

• Let there be only five chopsticks, one between each of the philosophers

42

• Let concurrent eating have these conditions

• 1. A philosopher tries to pick up the two chopsticks immediately on each side

– Picking up one chopstick is an independent act.

– It isn’t possible to pick up both simultaneously.

43

• 2. If a philosopher succeeds in acquiring the two chopsticks, then the philosopher can eat. – Eating cannot be interrupted

• 3. When the philosopher is done eating, the chopsticks are put down one after the other– Putting down one chopstick is an independent act.

– It isn’t possible to put down both simultaneously.

• Note that under these conditions it would not be possible for two neighboring philosophers to be eating at the same time

44

• This concurrency control problem has two challenges in it:

• 1. Starvation

• Due to the sequence of events, one philosopher may never be able to pick up two chopsticks and eat

45

• 2. Deadlock

• Due to the sequence of events, each philosopher may succeed in picking up either the chopstick on the left or the chopstick on the right.

– None will eat because they are waiting/attempting to pick up the other chopstick.

– Since they won’t be eating, they’ll never finish and put down the chopstick they do hold

46