Threads and Locks( ch 17, Java Language Specifications)
1. Synchronized
The synchronized statement performs two special actions relevant only to multithreaded operation:
As a convenience, a method may be declared synchronized; such a method behaves as if its body were contained in a synchronized statement.
2. Threads Working
Each thread has a working memory, in which it may keep copies of the values of variables from the main memory that is shared between all threads. To access a shared variable, a thread usually first obtains a lock and flushes its working memory. This guarantees that shared values will thereafter be loaded from the shared main memory to the threads working memory. When a thread unlocks a lock it guarantees the values it holds in its working memory will be written back to the main memory.
3. Variables
Variables are kept in a main memory that is shared by all threads. Because it is impossible for one thread to access parameters or local variables of another thread, it doesn't matter whether parameters and local variables are thought of as residing in the shared main memory or in the working memory of the thread that owns them.
4.Working 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. There are rules about when a thread is permitted or required to transfer the contents of its working copy of a variable into the master copy or vice versa.
The main memory also contains locks; there is one lock associated with each object. Threads may compete to acquire a lock.
5. Thread Actions
Here are the detailed definitions of each of the actions:
6. Thread Interaction
Threads do not interact directly; they communicate only through the shared main memory. The relationships between the actions of a thread and the actions of main memory are constrained in three ways:
7. There are also certain constraints on the read and write actions performed by main memory:
For every load action performed by any thread T on its working copy of a variable V, there must be a corresponding preceding read action by the main memory on the master copy of V, and the load action must put into the working copy the data transmitted by the corresponding read action.
For every store action performed by any thread T on its working copy of a variable V, there must be a corresponding following write action by the main memory on the master copy of V, and the write action must put into the master copy the data transmitted by the corresponding store action.
Let action A be a load or store by thread T on variable V, and let action P be the corresponding read or write by the main memory on variable V. Similarly, let action B be some other load or store by thread T on that same variable V, and let action Q be the corresponding read or write by the main memory on variable V. If A precedes B, then P must precede Q. (Less formally: actions on the master copy of any given variable on behalf of a thread are performed by the main memory in exactly the order that the thread requested.
1. Synchronized
The synchronized statement performs two special actions relevant only to multithreaded operation:
- After computing a reference to an object but before executing its body, it locks a lock associated with the object, and
- (2) after execution of the body has completed, either normally or abruptly, it unlocks that same lock.
As a convenience, a method may be declared synchronized; such a method behaves as if its body were contained in a synchronized statement.
2. Threads Working
Each thread has a working memory, in which it may keep copies of the values of variables from the main memory that is shared between all threads. To access a shared variable, a thread usually first obtains a lock and flushes its working memory. This guarantees that shared values will thereafter be loaded from the shared main memory to the threads working memory. When a thread unlocks a lock it guarantees the values it holds in its working memory will be written back to the main memory.
3. Variables
Variables are kept in a main memory that is shared by all threads. Because it is impossible for one thread to access parameters or local variables of another thread, it doesn't matter whether parameters and local variables are thought of as residing in the shared main memory or in the working memory of the thread that owns them.
4.Working 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. There are rules about when a thread is permitted or required to transfer the contents of its working copy of a variable into the master copy or vice versa.
The main memory also contains locks; there is one lock associated with each object. Threads may compete to acquire a lock.
5. Thread Actions
Here are the detailed definitions of each of the actions:
- A use action (by a thread) transfers the contents of the thread's working copy of a variable to the thread's execution engine. This action is performed whenever a thread executes a virtual machine instruction that uses the value of a variable.
- An assign action (by a thread) transfers a value from the thread's execution engine into the thread's working copy of a variable. This action is performed whenever a thread executes a virtual machine instruction that assigns to a variable.
- A read action (by the main memory) transmits the contents of the master copy of a variable to a thread's working memory for use by a later load action.
- A load action (by a thread) puts a value transmitted from main memory by a read action into the thread's working copy of a variable.
- A store action (by a thread) transmits the contents of the thread's working copy of a variable to main memory for use by a later write action.
- A write action (by the main memory) puts a value transmitted from the thread's working memory by a store action into the master copy of a variable in main memory.
- A lock action (by a thread tightly synchronized with main memory) causes a thread to acquire one claim on a particular lock.
- An unlock action (by a thread tightly synchronized with main memory) causes a thread to release one claim on a particular lock.
6. Thread Interaction
Threads do not interact directly; they communicate only through the shared main memory. The relationships between the actions of a thread and the actions of main memory are constrained in three ways:
- Each lock or unlock action is performed jointly by some thread and the main memory.
- Each load action by a thread is uniquely paired with a read action by the main memory such that the load action follows the read action.
- Each store action by a thread is uniquely paired with a write action by the main memory such that the write action follows the store action.
7. There are also certain constraints on the read and write actions performed by main memory:
For every load action performed by any thread T on its working copy of a variable V, there must be a corresponding preceding read action by the main memory on the master copy of V, and the load action must put into the working copy the data transmitted by the corresponding read action.
For every store action performed by any thread T on its working copy of a variable V, there must be a corresponding following write action by the main memory on the master copy of V, and the write action must put into the master copy the data transmitted by the corresponding store action.
Let action A be a load or store by thread T on variable V, and let action P be the corresponding read or write by the main memory on variable V. Similarly, let action B be some other load or store by thread T on that same variable V, and let action Q be the corresponding read or write by the main memory on variable V. If A precedes B, then P must precede Q. (Less formally: actions on the master copy of any given variable on behalf of a thread are performed by the main memory in exactly the order that the thread requested.
Fixing the Java Memory Model, Part 1
Memory model describes the relationship between variables in a program (instance fields, static fields, and array elements) and the low-level details of storing them to and retrieving them from memory in a real computer system. Objects are ultimately stored in memory, but the compiler, runtime, processor, or cache may take some liberties with the timing of moving values to or from a variable's assigned memory location.
The JMM allows the compiler and cache to take significant liberties with the order in which data is moved between a processor-specific cache (or register) and main memory, unless the programmer has explicitly asked for certain visibility guarantees using synchronized or volatile. This means that in the absence of synchronization, memory operations can appear to happen in different orders from the perspective of different threads.
By contrast, languages like C and C++ do not have explicit memory models -- C programs instead inherit the memory model of the processor executing the program. Program may fail on a different processor architecture. While the JMM may be confusing at first, there is a significant benefit to it -- a program that is correctly synchronized according to the JMM should run correctly on any Java-enabled platform.
Memory model describes the relationship between variables in a program (instance fields, static fields, and array elements) and the low-level details of storing them to and retrieving them from memory in a real computer system. Objects are ultimately stored in memory, but the compiler, runtime, processor, or cache may take some liberties with the timing of moving values to or from a variable's assigned memory location.
The JMM allows the compiler and cache to take significant liberties with the order in which data is moved between a processor-specific cache (or register) and main memory, unless the programmer has explicitly asked for certain visibility guarantees using synchronized or volatile. This means that in the absence of synchronization, memory operations can appear to happen in different orders from the perspective of different threads.
By contrast, languages like C and C++ do not have explicit memory models -- C programs instead inherit the memory model of the processor executing the program. Program may fail on a different processor architecture. While the JMM may be confusing at first, there is a significant benefit to it -- a program that is correctly synchronized according to the JMM should run correctly on any Java-enabled platform.
