CSC/ECE 506 Spring 2011/ch10 MC - Revision history

Admin: /* The JMM Specifications */

2011-05-02T04:34:57Z

The JMM Specifications

← Older revision		Revision as of 04:34, 2 May 2011
Line 31:		Line 31:
	* '''Program-order rule''': Each action in a thread ''happens-before'' every action in that thread that comes later in the program order.		* '''Program-order rule''': Each action in a thread ''happens-before'' every action in that thread that comes later in the program order.
	* '''Monitor-lock rule''': An unlock on a monitor lock ''happens-before'' every subsequent lock on that same monitor lock.		* '''Monitor-lock rule''': An unlock on a monitor lock ''happens-before'' every subsequent lock on that same monitor lock.
	* '''Volatile-variable rule''': A write to a volatile ~~filed~~ ''happens-before'' every subsequent read of that same field.		* '''Volatile-variable rule''': A write to a volatile field ''happens-before'' every subsequent read of that same field.
	* '''Thread-start rule''': A call to <tt>Thread.Start</tt> on a thread ''happens-before'' every action in the started thread.		* '''Thread-start rule''': A call to <tt>Thread.Start</tt> on a thread ''happens-before'' every action in the started thread.
	* '''Thread-termination rule''': Any action in a thread ''happens-before'' any other thread detects that thread has terminated, either by successfully return from <tt>Thread.join or by <tt>Thread.isAlive</tt> returning false.		* '''Thread-termination rule''': Any action in a thread ''happens-before'' any other thread detects that thread has terminated, either by successfully return from <tt>Thread.join or by <tt>Thread.isAlive</tt> returning false.

Briyenga: /* Concurrency-related building blocks in Java */

2011-04-10T02:45:30Z

Concurrency-related building blocks in Java

← Older revision		Revision as of 02:45, 10 April 2011
Line 20:		Line 20:

	==Concurrency-related building blocks in Java==		==Concurrency-related building blocks in Java==
	Java includes several language constructs, including <tt>volatile</tt>, <tt>final</tt>, and <tt>synchronized</tt>, which are intended to help the programmer describe a program's concurrency requirements to the compiler. The Java Memory Model defines the behavior of <tt>volatile</tt> and <tt>synchronized</tt>, and, more importantly, ensures that a correctly synchronized Java program runs correctly on all processor architectures.		Java includes several language constructs, including <tt>volatile</tt>, <tt>final</tt>, and <tt>synchronized</tt>, which are intended to help the programmer describe a program's concurrency requirements to the compiler. Each programming language defines the behavior of <tt>volatile</tt> variables differently, however, in general it implies that it prevents the compiler from applying any optimizations on accesses to these variables, for e.g., these variables generally are not cached in registers and are read from memory each time. The <tt>final</tt> keyword is used in several different contexts to define an entity which cannot later be changed. A <tt>final</tt> class cannot be extended, a <tt>final</tt> method cannot be overridden by subclasses and a <tt>final<tt> variable can only be assigned once. The Java Memory Model defines the behavior of <tt>volatile</tt> and <tt>synchronized</tt>, and, more importantly, ensures that a correctly synchronized Java program runs correctly on all processor architectures.

	==The JMM Specifications==		==The JMM Specifications==

Briyenga: /* Introduction */

2011-04-10T02:37:24Z

Introduction

← Older revision		Revision as of 02:37, 10 April 2011
Line 1:		Line 1:
	=Supplement to Chapter 10: Memory Consistency Models=		=Supplement to Chapter 10: Memory Consistency Models=
	==Introduction==		==Introduction==
	Memory consistency deals with visibility of the ordering of memory accesses to shared data across processors (or cores) in a multiprocessor environment. Memory consistency models define frameworks that outline what programmers can expect when writing multi-threaded programs using shared memory. We briefly discuss the guarantees provided by the hardware memory model. We then look at the motivation of defining the memory model at the programming language level. The Java programming model was designed ground up with a memory model in mind, this has resulted in language features that allow it to enforce the Java Memory Model (JMM) in a manner that is transparent to the Java programmer. We look at some of the building blocks in the Java programming language to enforce the JMM. We follow that up with a detailed discussion of the JMM ~~and some~~ of the ~~related issues~~.		Memory consistency deals with visibility of the ordering of memory accesses to shared data across processors (or cores) in a multiprocessor environment. Memory consistency models define frameworks that outline what programmers can expect when writing multi-threaded programs using shared memory. We briefly discuss the guarantees provided by the hardware memory model. We then look at the motivation of defining the memory model at the programming language level. The Java programming model was designed ground up with a memory model in mind, this has resulted in language features that allow it to enforce the Java Memory Model (JMM) in a manner that is transparent to the Java programmer. We look at some of the building blocks in the Java programming language to enforce the JMM. We follow that up with a detailed discussion of the JMM. After discussing the JMM, we look at ''safe'' ways to elide unnecessary synchronization by using the guarantees that the JMM provides. We look at programming idioms that should be used for ''safe'' initialization of objects by considering the invariants that the JMM provides. We discuss the Double-Checked Locking idiom that is an example of incorrect elision of the ''synchronized'' construct and explain why it is broken. We round off by looking at useful thumb rules to write ''safe'' Java code.

	=The Java Memory Model=		=The Java Memory Model=

Briyenga: /* Double-Checked Locking */

2011-04-10T02:18:02Z

Double-Checked Locking

← Older revision		Revision as of 02:18, 10 April 2011
Line 70:		Line 70:

	==Double-Checked Locking==		==Double-Checked Locking==
	Lazy initialization has often been used to reduce startup time for an application, or to avoid expensive operations that are potentially unnecessary. A properly written lazy-initialization method requires synchronization; however synchronization was perceived as expensive and the ''visibility'' aspects of synchronization were not completely understood. This resulted in the invention of the ''double-checked locking'' (DCL) paradigm, which tries to offer lazy initialization without paying the synchronization penalty on the common code path. Double-checked locking first checks--without synchronizing--whether initialization is needed, and if the resource reference is not null, it can be used immediately. Otherwise, the thread synchronizes again and checks again whether the ''resource'' is initialized, ensuring that only one thread actually initializes the shared ''resource''. The common code path--fetching a reference to an already constructed resource~~--doesn't use~~ synchronization. This, however, results in the problem because there is no ''happens-before'' edge between the ''unsynchronized'' reader of the reference and the publisher of the reference to the resource. This ~~makes it possible for a~~ reader to see a partially constructed resource.		Lazy initialization, has often been used to reduce startup time for an application, or to avoid expensive operations that are potentially unnecessary. The goal of ''Lazy-initialization'' is to defer initializing an object unitl it is actually needed while at the same time ensuring that it is initialized only once. A properly written lazy-initialization method requires synchronization; however synchronization was perceived as expensive and something to be avoided. In addition, the ''visibility'' aspects of synchronization, were not completely understood.
			This resulted in the invention of the ''double-checked locking'' (DCL) paradigm, which tries to offer lazy initialization without paying the synchronization penalty on the common code path. Double-checked locking first checks--without synchronizing--whether initialization is needed, and if the resource reference is not null, it can be used immediately. Otherwise, the thread synchronizes again and checks again whether the ''resource'' is initialized, ensuring that only one thread actually initializes the shared ''resource''. The common code path is generally the one fetching a reference to an already constructed resource and this idiom elides synchronization in this path. This, however, results in the problem because there is no ''happens-before'' edge between the ''unsynchronized'' reader of the reference and the publisher of the reference to the resource. This implies that the reader can see a partially constructed resource.

	The code snippet below shows an example of the DCL idiom.		The code snippet below shows an example of the DCL idiom.

Briyenga: /* Safe Initialization */

2011-04-10T01:16:10Z

Safe Initialization

← Older revision		Revision as of 01:16, 10 April 2011
Line 67:		Line 67:
	It is important to initialize the objects completely and to ensure that the object state is entirely visible before publishing a reference to the newly constructed object to other threads. This can be done easily by using the <tt>synchronized</tt> keyword on the constructor. The treatment of static fields with initializers (of fields whose value is initialized in a static initialization block) offers additional thread-safety guarantees. Static initializers are run by the JVM at class-initialization time, after class loading but before the class is used by any thread. Because the JVM acquires a lock during initialization and this lock is acquired by each thread at least once to ensure that the class has been loaded, memory writes made during static initialization are automatically visible to all threads. Thus statically initialized objects require no explicit synchronization either during construction or when being referenced. This only applies to the ''as-constructed'' state-- if the object is mutable, synchronization is still required by both readers and writers to make subsequent modifications visible and to avoid data corruption.		It is important to initialize the objects completely and to ensure that the object state is entirely visible before publishing a reference to the newly constructed object to other threads. This can be done easily by using the <tt>synchronized</tt> keyword on the constructor. The treatment of static fields with initializers (of fields whose value is initialized in a static initialization block) offers additional thread-safety guarantees. Static initializers are run by the JVM at class-initialization time, after class loading but before the class is used by any thread. Because the JVM acquires a lock during initialization and this lock is acquired by each thread at least once to ensure that the class has been loaded, memory writes made during static initialization are automatically visible to all threads. Thus statically initialized objects require no explicit synchronization either during construction or when being referenced. This only applies to the ''as-constructed'' state-- if the object is mutable, synchronization is still required by both readers and writers to make subsequent modifications visible and to avoid data corruption.

	Initialization safety guarantees that for ''properly constructed'' objects, all threads will see the correct values of final fields that were set by the constructor, regardless of how the object is published. Further, any variables that can be ''reached'' through a final field of a properly constructed object (such as the elements of a final array or the contents of a HashMap referenced by a final field) are also guaranteed to be visible to other threads.( [[#References \| Goetz]])		Initialization safety guarantees that for ''properly constructed'' objects, all threads will see the correct values of final fields that were set by the constructor, regardless of how the object is published. ''Publishing'' an object means making it available to code outside of its current scope, such as by storing a reference to it where other code can find it, returning it from a non-private method, or passing it to a method in another class. Further, any variables that can be ''reached'' through a final field of a properly constructed object (such as the elements of a final array or the contents of a HashMap referenced by a final field) are also guaranteed to be visible to other threads.( [[#References \| Goetz]])

	==Double-Checked Locking==		==Double-Checked Locking==

Briyenga: /* Piggybacking on synchronization */

2011-04-10T01:13:04Z

Piggybacking on synchronization

← Older revision		Revision as of 01:13, 10 April 2011
Line 55:		Line 55:

	==Piggybacking on synchronization==		==Piggybacking on synchronization==
	Since the JMM guarantees ''happens-before'' ordering in the cases listed above, it is possible to piggyback on the visibility properties of an existing synchronization. This is commonly done in class libraries. A Java developer, however, should be careful in using this technique as it assumes a good understanding of the JMM and can be fragile otherwise. The ''happens-before'' orderings guaranteed by the class library include:		Since the JMM guarantees ''happens-before'' ordering in the cases listed above, it is possible to piggyback on the visibility properties of an existing synchronization. This entails combining the program order rule for ''happens-before'' with one of the other ordering rules (usually the monitor lock or volatile variable rule) to order accesses to a variable not otherwise guarded by a lock. This technique is called ''piggybacking'' because it uses an existing ''happens-before'' ordering that was created for some other reason to ensure the visibility of an object, rather than creating a ''happens-before'' ordering specifically for publishing the object.
			This is commonly done in class libraries. A Java developer, however, should be careful in using this technique as it assumes a good understanding of the JMM and can be fragile otherwise. The ''happens-before'' orderings guaranteed by the class library include:

	* Placing an item in a thread-safe collection ''happens-before'' another thread retrieves that item from the collection		* Placing an item in a thread-safe collection ''happens-before'' another thread retrieves that item from the collection

Briyenga: /* Safe Initialization */

2011-04-10T01:07:40Z

Safe Initialization

← Older revision		Revision as of 01:07, 10 April 2011
Line 64:		Line 64:

	==Safe Initialization==		==Safe Initialization==
	It is important to initialize the objects completely and to ensure that the object state is entirely visible before publishing a reference to the newly constructed object to other threads. This can be done easily by ~~making~~ using the <tt>synchronized</tt> keyword on the constructor. The treatment of static fields with initializers (of fields whose value is initialized in a static initialization block) offers additional thread-safety guarantees. Static initializers are run by the JVM at class-initialization time, after class loading but before the class is used by any thread. Because the JVM acquires a lock during initialization and this lock is acquired by each thread at least once to ensure that the class has been loaded, memory writes made during static initialization are automatically visible to all threads. Thus statically initialized objects require no explicit synchronization either during construction or when being referenced. This only applies to the ''as-constructed'' state-- if the object is mutable, synchronization is still required by both readers and writers to make subsequent modifications visible and to avoid data corruption.		It is important to initialize the objects completely and to ensure that the object state is entirely visible before publishing a reference to the newly constructed object to other threads. This can be done easily by using the <tt>synchronized</tt> keyword on the constructor. The treatment of static fields with initializers (of fields whose value is initialized in a static initialization block) offers additional thread-safety guarantees. Static initializers are run by the JVM at class-initialization time, after class loading but before the class is used by any thread. Because the JVM acquires a lock during initialization and this lock is acquired by each thread at least once to ensure that the class has been loaded, memory writes made during static initialization are automatically visible to all threads. Thus statically initialized objects require no explicit synchronization either during construction or when being referenced. This only applies to the ''as-constructed'' state-- if the object is mutable, synchronization is still required by both readers and writers to make subsequent modifications visible and to avoid data corruption.

	Initialization safety guarantees that for ''properly constructed'' objects, all threads will see the correct values of final fields that were set by the constructor, regardless of how the object is published. Further, any variables that can be ''reached'' through a final field of a properly constructed object (such as the elements of a final array or the contents of a HashMap referenced by a final field) are also guaranteed to be visible to other threads.( [[#References \| Goetz]])		Initialization safety guarantees that for ''properly constructed'' objects, all threads will see the correct values of final fields that were set by the constructor, regardless of how the object is published. Further, any variables that can be ''reached'' through a final field of a properly constructed object (such as the elements of a final array or the contents of a HashMap referenced by a final field) are also guaranteed to be visible to other threads.( [[#References \| Goetz]])

	==Double-Checked Locking==		==Double-Checked Locking==

Briyenga: /* Motivation for the Java Memory Model */

2011-04-10T01:03:50Z

Motivation for the Java Memory Model

← Older revision		Revision as of 01:03, 10 April 2011
Line 5:		Line 5:
	=The Java Memory Model=		=The Java Memory Model=
	==Motivation for the Java Memory Model==		==Motivation for the Java Memory Model==
	Chapter 10 of [[#References \| Solihin (2009)]] looks at what is specified by the memory model at the hardware level and why it is required. At the processor level, a memory model defines necessary and sufficient conditions for knowing that writes to memory by other processors are visible to the current processor, and writes by the current processor are visible to other processors. Some processors exhibit a strong memory model, where all processors see ~~exactly~~ the same ~~value for any given~~ memory location ~~at all times~~. Other processors exhibit a weaker memory model, where special instructions, called memory barriers, are required to flush or invalidate the local processor cache in order to see writes made by other processors or make writes by this processor visible to others. These memory barriers are usually performed when lock and unlock actions are taken. Even on some of the strongest memory models, memory barriers are often necessary; quite frequently their placement is counterintuitive. Recent trends in processor design have encouraged weaker memory models, because the relaxations they make for cache consistency allow for greater scalability across multiple processors and larger amounts of memory.		Chapter 10 of [[#References \| Solihin (2009)]] looks at what is specified by the memory model at the hardware level and why it is required. At the processor level, a memory model defines necessary and sufficient conditions for knowing that writes to memory by other processors are visible to the current processor, and writes by the current processor are visible to other processors. Some processors exhibit a strong memory model, where all processors see the same sequence of changes to a memory location. Other processors exhibit a weaker memory model, where special instructions, called memory barriers, are required to flush or invalidate the local processor cache in order to see writes made by other processors or make writes by this processor visible to others. These memory barriers are usually performed when lock and unlock actions are taken. Even on some of the strongest memory models, memory barriers are often necessary; quite frequently their placement is counterintuitive. Recent trends in processor design have encouraged weaker memory models, because the relaxations they make for cache consistency allow for greater scalability across multiple processors and larger amounts of memory.

	The issue of when a write becomes visible to another thread is compounded by the compiler's reordering of code. For example, the compiler might decide that it is more efficient to move a write operation later in the program; as long as this code motion does not change the program's semantics, it is free to do so. If a compiler defers an operation, another thread will not see it until it is performed; this mirrors the effect of caching. Most languages provide keywords such as "volatile" to get around compiler reordering of memory accesses.		The issue of when a write becomes visible to another thread is compounded by the compiler's reordering of code. For example, the compiler might decide that it is more efficient to move a write operation later in the program; as long as this code motion does not change the program's semantics, it is free to do so. If a compiler defers an operation, another thread will not see it until it is performed; this mirrors the effect of caching. Most languages provide keywords such as "volatile" to get around compiler reordering of memory accesses.

Briyenga: /* References */

2011-04-10T01:01:34Z

References

← Older revision		Revision as of 01:01, 10 April 2011
Line 90:		Line 90:
	# Jeremy Manson, William Pugh and Sarita Adve, ''The Java Memory Model'' http://rsim.cs.illinois.edu/Pubs/popl05.pdf		# Jeremy Manson, William Pugh and Sarita Adve, ''The Java Memory Model'' http://rsim.cs.illinois.edu/Pubs/popl05.pdf
	# Bill Pugh ''JMM Page'' http://www.cs.umd.edu/~pugh/java/memoryModel/		# Bill Pugh ''JMM Page'' http://www.cs.umd.edu/~pugh/java/memoryModel/
	# Brian Goetz, ''Java Concurrency in Practice'',		# Brian Goetz With Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea, ''Java Concurrency in Practice'', Addison-Wesley, 2006.
	# Reentrant Mutex http://en.wikipedia.org/wiki/Reentrant_mutex		# Reentrant Mutex http://en.wikipedia.org/wiki/Reentrant_mutex
	# Jeremy Manson, William Pugh and Sarita Adve ''The Java Memory Model'' http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf		# Jeremy Manson, William Pugh and Sarita Adve ''The Java Memory Model'' http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf

Admin: /* Writing safe Java code */

2011-04-09T21:32:33Z

Writing safe Java code

← Older revision		Revision as of 21:32, 9 April 2011
Line 83:		Line 83:
	=Writing safe Java code=		=Writing safe Java code=

	The Java memory model along with the [http://en.wikipedia.org/wiki/Java_Development_Kit/ JDK], makes it easier for Java programmers to write safe concurrent programs. Java programmers should use concurrency abstractions provided by the JDK libraries, i.e., <tt>java.util.concurrent</tt>, <tt>java.util.concurrent.locks</tt> and <tt>synchronized</tt> blocks. Programmers can also use low level primitives such as <tt>volatile</tt> variables and ''atomic'' classes in the JDK if they need to implement safe non-blocking synchronization. The <tt>java.util.concurrent.atomic</tt> provides a toolkit of classes that support lock-free thread-safe programming on single variables. Java programmers are strongly encouraged to use lock-based thread-safety constructs such as <tt>synchronized</tt> blocks, modern JVM's implement optimizations such as [http://www.research.ibm.com/people/d/dfb/papers/Bacon03Retrospective.pdf thin-locks] and [http://blogs.sun.com/dave/entry/biased_locking_in_hotspot biased locking] to reduce the overhead of locks significantly.		The Java memory model, along with the [http://en.wikipedia.org/wiki/Java_Development_Kit/ JDK], makes it easier for Java programmers to write safe concurrent programs. Java programmers should use concurrency abstractions provided by the JDK libraries, i.e., <tt>java.util.concurrent</tt>, <tt>java.util.concurrent.locks</tt> and <tt>synchronized</tt> blocks. Programmers can also use low-level primitives such as <tt>volatile</tt> variables and ''atomic'' classes in the JDK if they need to implement safe non-blocking synchronization. The <tt>java.util.concurrent.atomic</tt> provides a toolkit of classes that support lock-free thread-safe programming on single variables. Java programmers are strongly encouraged to use lock-based thread-safety constructs such as <tt>synchronized</tt> blocks, modern JVM's implement optimizations such as [http://www.research.ibm.com/people/d/dfb/papers/Bacon03Retrospective.pdf thin-locks] and [http://blogs.sun.com/dave/entry/biased_locking_in_hotspot biased locking] to reduce the overhead of locks significantly.

	=References=		=References=