Java Thread and Memory Model

By Xijun Zhang

#104549

Question

• Can this result in i = 0 and j = 0?

x=y=0

x=1 y=1

i=y j=x

Thread 1 Thread 2

Contents

• Thread review

• Threads in Java

• Programmer’s view of Java memory model

Threads• Has an execution state (running, ready, etc.)

• Saves thread context when not running

• Has an execution stack and some per-thread static storage for local variables

• Has access to the memory address space and resources of its process– all threads of a process share this– when one thread alters a (non-private) memory

item, all other threads (of the process) sees that– a file open with one thread, is available to

others

Single Threaded and Multithreaded Process Models

• Thread Control Block contains a register image, thread priority and thread state information

Benefits of Threads vs Processes

• Takes less time to create a new thread than a process

• Less time to terminate a thread than a process

• Less time to switch between two threads within the same process

Benefits of Threads

• Since threads within the same process share memory and files, they can communicate with each other without invoking the kernel

• Therefore necessary to synchronize the activities of various threads so that they do not obtain inconsistent views of the data

Java Thread Support Reside in Three Places

• The java.lang.Thread class

• The java.lang.Object class

• The Java language and virtual machine

Two ways to create threads

• Extending the java.lang.Thread class

• Implementing the java.lang.Runnable interface

Extending the Thread class

• Can build a thread by extending java.lang.Thread class

• You must supply a public void run() method

• Start a thread by invoking the start() method

• When a thread starts, it executes run() method

• When run() finished, the thread is finished/dead

Interface Runnable• Extending Thread means can’t extend anything else

• Instead implement Runnable (Declares an object has a void run() method)

• Creating a new thread by giving is an object of type Runnable

• Constructors:

Thread(Runnable target)

Thread(Runnable target, String name)

Thread States

• Running: The state that all threads aspire to

• Various waiting states: Waiting, Sleeping, Suspended, Blocked

• Ready: Not waiting for anything except the CPU

• Dead: All done

Two approaches to implement Thread schedulers

• Preemptive scheduling (e.g. Solaris)

• Time-sliced or round-robin scheduling

e.g. Macintosh, Windows

• Java Thread is platform dependent

Synchronization

• Threads share the same memory space, i.e. they can share resources

• It is desirable that only one thread at a time has access to a shared resource

• Java use the key word synchronized for critical section

Monitors

• At any given time, no more than one thread can own the monitor and thereby have access to the shared resource

• A monitor thus implements a mutually exclusive locking mechanism

• All Java objects have a monitor, and each object can be used as a mutually exclusive lock, providing the ability to synchronize access to shared resources

Synchronized Methods

• A method can be synchronized (add synchronized before the return type)

• Obtains a lock on object referenced by this before starting method ( releases lock when method completes)

• A static synchronized method (locks the class object)

Synchronized statement

• synchronized (obj) {block}

• Obtains a lock on obj before executing block

• Releases lock once block completes

• Provides finer grain of control

• Allows you to lock arguments to a method

Using wait

• a.wait()

--gives up locks on a

--adds thread to wait set for a

--suspends thread

• a.wait(int m)

--limits suspension to m milliseconds

Using notify

• a.notify() resumes one thread from a’s waiting list and remove it from wait set, no control over which thread

• a.notifyAll() resumes one thread on a’s

waiting list

• resumed task must reacquire lock before continuing

Synchronization

• Atomicity

--locking to obtain mutual exclusion

--Atomic read/write granularity• Visibility

--ensuring that changes in object fields on one object are seen in another thread

• Ordering

--ensuring that you aren’t surprised by the order in which statements are executed

Question

• Can this result in i=0 and j=0?

x=y=0

x=1 y=1

i=y j=x

Thread 1 Thread 2

Answer: Yes!

x=y=0

x=1 y=1

i=y j=x

Thread 1 Thread 2

• How can i=0 and j=0?

Working Memory v.s. Main Memory

• Every thread has a working memory in which it keeps its own working copy of variables that it must use or assign. As the thread executes a program, it operates on these working copies.

• The main memory contains the master copy of every variable.

Low level actionsthread

use assign

Working memory(register, cache)

store load

write read

main memory

How can this happen?

• Compiler can reorder statement or keep values in registers

• Processor can reorder them

• On multiprocessor, values not synchronized in global memory

• Must use synchronization to enforce visibility and ordering as well as mutual exclusion

Synchronization Action//block until obtain lock

synchronized (anObject) {

//get main memory value of field1 and field2

int x = anObject.field1;

int y = anObject.field2;

anObject.field3 = x + y;

//commit value of field3 to main memory

}

// release lock

moreCode();

When are actions visible to other thread?

Thread 1

x=1

unlock M

Thread 2 lock M

i=x

What does volatile mean?

• C/C++ spec

--There is no implementation independent meaning of volatile

• Situation a little better with Java Technology

--volatile reads/writes guaranteed to go directly to main memory

e.g. can’t be cached in registers or local memory

Using volatile• Volatile used to guarantee visibility of writes

--stop() must be declared volatile

--Otherwise, compiler could keep in register

class Animator implements Runnable {

private volatile boolean stop = false;

public void stop() { stop = true;}

public void run() {

while (!stop) oneStep();

}

private void oneStep() {/*……*/}

}

Some problems of current Java Memory Model

• Some JVMs do not implement volatile correctly

• There are some corner cases

• Experts are trying to fix the current JMM