Java concurrency

Last updated

The Java programming language and the Java virtual machine (JVM) is designed to support concurrent programming. All execution takes place in the context of threads. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "synchronized") between threads. [1] [2] Thread synchronization ensures that objects are modified by only one thread at a time and prevents threads from accessing partially updated objects during modification by another thread. [2] The Java language has built-in constructs to support this coordination.

Contents

Processes and threads

Most implementations of the Java virtual machine run as a single process. In the Java programming language, concurrent programming is primarily concerned with threads (also called lightweight processes). Multiple processes can only be realized with multiple JVMs.

Thread objects

Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication. [2] Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as Runnable or Callable objects. The Callable interface is similar to Runnable in that both are designed for classes whose instances are potentially executed by another thread. [3] A Runnable, however, does not return a result and cannot throw a checked exception. [4]

Each thread can be scheduled [5] on a different CPU core [6] or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can so this differently.

Each thread is associated with an instance of the class Thread. Threads can be managed either by directly using the Thread objects, or indirectly by using abstract mechanisms such as Executors or Tasks. [7]

Starting a Thread

Two ways to start a Thread:

Provide a runnable object
publicclassHelloRunnableimplementsRunnable{@Overridepublicvoidrun(){System.out.println("Hello from thread!");}publicstaticvoidmain(String[]args){(newThread(newHelloRunnable())).start();}}
Subclass thread
publicclassHelloThreadextendsThread{@Overridepublicvoidrun(){System.out.println("Hello from thread!");}publicstaticvoidmain(String[]args){(newHelloThread()).start();}}

Interrupts

An interrupt tells a thread that it should stop what it is doing and do something else. A thread sends an interrupt by invoking interrupt() on the Thread object for the thread to be interrupted. The interrupt mechanism is implemented using an internal boolean flag known as the "interrupted status". [8] Invoking interrupt() sets this flag. [9] By convention, any method that exits by throwing an InterruptedException clears the interrupted status when it does so. However, it's always possible that the interrupted status will immediately be set again, by another thread invoking interrupt().

Joins

The java.lang.Thread#join() method allows one Thread to wait for the completion of another.

Exceptions

Uncaught exceptions thrown by code will terminate the thread. The main thread prints exceptions to the console, but user-created threads need a handler registered to do so. [10] [11]

Memory model

The Java memory model describes how threads in the Java programming language interact through memory. On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. The Java programming language does not guarantee linearizability, or even sequential consistency [12] , when reading or writing fields of shared objects, and this is to allow for compiler optimizations (such as register allocation, common subexpression elimination, and redundant read elimination) all of which work by reordering memory reads—writes. [13]

Synchronization

Threads communicate primarily by sharing access to fields and the objects that reference fields refer to. This form of communication is extremely efficient, but makes two kinds of errors possible: thread interference and memory consistency errors. The tool needed to prevent these errors is synchronization.

Reorderings can come into play in incorrectly synchronized multithreaded programs, where one thread is able to observe the effects of other threads, and may be able to detect that variable accesses become visible to other threads in a different order than executed or specified in the program. Most of the time, one thread doesn't care what the other is doing. But when it does, that's what synchronization is for.

To synchronize threads, Java uses monitors, which are a high-level mechanism for allowing only one thread at a time to execute a region of code protected by the monitor. The behavior of monitors is explained in terms of locks; there is a lock associated with each object.

Synchronization has several aspects. The most well-understood is mutual exclusion—only one thread can hold a monitor at once, so synchronizing on a monitor means that once one thread enters a synchronized block protected by a monitor, no other thread can enter a block protected by that monitor until the first thread exits the synchronized block. [2]

But there is more to synchronization than mutual exclusion. Synchronization ensures that memory writes by a thread before or during a synchronized block are made visible in a predictable manner to other threads which synchronize on the same monitor. After we exit a synchronized block, we release the monitor, which has the effect of flushing the cache to main memory, so that writes made by this thread can be visible to other threads. Before we can enter a synchronized block, we acquire the monitor, which has the effect of invalidating the local processor cache so that variables will be reloaded from main memory. We will then be able to see all of the writes made visible by the previous release.

Reads—writes to fields are linearizable if either the field is volatile, or the field is protected by a unique lock which is acquired by all readers and writers.

Locks and synchronized blocks

A thread can achieve mutual exclusion either by entering a synchronized block or method, which acquires an implicit lock [14] [2] , or by acquiring an explicit lock (such as the ReentrantLock from the java.util.concurrent.locks package [15] ). Both approaches have the same implications for memory behavior. If all accesses to a particular field are protected by the same lock, then reads—writes to that field are linearizable (atomic).

Volatile fields

When applied to a field, the Java volatile keyword guarantees that:

  1. (In all versions of Java) There is a global ordering on the reads and writes to a volatile variable. This implies that every thread accessing a volatile field will read its current value before continuing, instead of (potentially) using a cached value. (However, there is no guarantee about the relative ordering of volatile reads and writes with regular reads and writes, meaning that it's generally not a useful threading construct.)
  2. (In Java 5 or later) Volatile reads and writes establish a happens-before relationship, much like acquiring and releasing a mutex. [16] This relationship is simply a guarantee that memory writes by one specific statement are visible to another specific statement.

A volatile fields are linearizable. Reading a volatile field is like acquiring a lock: the working memory is invalidated and the volatile field's current value is reread from memory. Writing a volatile field is like releasing a lock: the volatile field is immediately written back to memory.

Final fields

A field declared to be final cannot be modified once it has been initialized. [17] An object's final fields are initialized in its constructor. As long as the this reference is not released from the constructor before the constructor returns, then the correct value of any final fields will be visible to other threads without synchronization. [18]

History

Since JDK 1.2, Java has included a standard set of collection classes, the Java collections framework

Doug Lea, who also participated in the Java collections framework implementation, developed a concurrency package, comprising several concurrency primitives and a large battery of collection-related classes. [19] This work was continued and updated as part of JSR 166 which was chaired by Doug Lea.

JDK 5.0 incorporated many additions and clarifications to the Java concurrency model. The concurrency APIs developed by JSR 166 were also included as part of the JDK for the first time. JSR 133 provided support for well-defined atomic operations in a multithreaded/multiprocessor environment.

Both the Java SE 6 and Java SE 7 releases introduced updated versions of the JSR 166 APIs as well as several new additional APIs.

See also

Notes

  1. ↑ Goetz et al. 2006, pp. 15–17, §2 Thread Safety.
  2. 1 2 3 4 5 Bloch 2018, pp. 126–129, Chapter §11 Item 78: Synchronize access to shared mutable data.
  3. ↑ Goetz et al. 2006, pp. 125–126, §6.3.2 Result-bearing tasks: Callable and Future.
  4. ↑ Goetz et al. 2006, pp. 95–98, §5.5.2 FutureTask.
  5. ↑ Bloch 2018, pp. 336–337, Chapter §11 Item 84 Don't depend on the thread scheduler.
  6. ↑ Bloch 2018, p. 311, Chapter §11 Concurrency.
  7. ↑ Bloch 2018, pp. 323–324, Chapter §5 Item 80: Prefer executors, tasks, and streams to threads.
  8. ↑ Goetz et al. 2006, pp. 138–141, §7.1.1 Interruption.
  9. ↑ Goetz et al. 2006, pp. 92–94, §5.4 Blocking and interruptible methods.
  10. ↑ Oracle. "Interface Thread.UncaughtExceptionHandler" . Retrieved 10 May 2014.
  11. ↑ "Silent Thread death from unhandled exceptions". literatejava.com. Retrieved 10 May 2014.
  12. ↑ Goetz et al. 2006, pp. 338–339, §16.1.1 Platform memory models.
  13. ↑ Herlihy, Maurice, and Nir Shavit. "The art of multiprocessor programming." PODC. Vol. 6. 2006.
  14. ↑ Goetz et al. 2006, pp. 25–26, §2.3.1 Intrinsic locks.
  15. ↑ Goetz et al. 2006, pp. 277–278, §13 Explicit Locks.
  16. ↑ Section 17.4.4: Synchronization Order "The Java® Language Specification, Java SE 7 Edition". Oracle Corporation. 2013. Retrieved 2013-05-12.
  17. ↑ Goetz et al. 2006, p. 48, §3.4.1 Final fields.
  18. ↑ Goetz et al. 2006, pp. 41–42, §3.2.1 Safe construction practices.
  19. ↑ Doug Lea. "Overview of package util.concurrent Release 1.3.4" . Retrieved 2011-01-01. Note: Upon release of J2SE 5.0, this package enters maintenance mode: Only essential corrections will be released. J2SE5 package java.util.concurrent includes improved, more efficient, standardized versions of the main components in this package.

Related Research Articles

<span class="mw-page-title-main">Mutual exclusion</span> In computing, restricting data to be accessible by one thread at a time

In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions. It is the requirement that one thread of execution never enters a critical section while a concurrent thread of execution is already accessing said critical section, which refers to an interval of time during which a thread of execution accesses a shared resource or shared memory.

Thread safety is a computer programming concept applicable to multi-threaded code. Thread-safe code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction. There are various strategies for making thread-safe data structures.

In concurrent programming, guarded suspension is a software design pattern for managing operations that require both a lock to be acquired and a precondition to be satisfied before the operation can be executed. The guarded suspension pattern is typically applied to method calls in object-oriented programs, and involves suspending the method call, and the calling thread, until the precondition is satisfied.

In software engineering, double-checked locking is a software design pattern used to reduce the overhead of acquiring a lock by testing the locking criterion before acquiring the lock. Locking occurs only if the locking criterion check indicates that locking is required.

In computer science, a lock or mutex is a synchronization primitive: a mechanism that enforces limits on access to a resource when there are many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy, and with a variety of possible methods there exists multiple unique implementations for different applications.

In computer science, read-copy-update (RCU) is a synchronization mechanism that avoids the use of lock primitives while multiple threads concurrently read and update elements that are linked through pointers and that belong to shared data structures.

In computer science, an algorithm is called non-blocking if failure or suspension of any thread cannot cause failure or suspension of another thread; for some operations, these algorithms provide a useful alternative to traditional blocking implementations. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress, and wait-free if there is also guaranteed per-thread progress. "Non-blocking" was used as a synonym for "lock-free" in the literature until the introduction of obstruction-freedom in 2003.

In computer science, compare-and-swap (CAS) is an atomic instruction used in multithreading to achieve synchronization. It compares the contents of a memory location with a given value and, only if they are the same, modifies the contents of that memory location to a new given value. This is done as a single atomic operation. The atomicity guarantees that the new value is calculated based on up-to-date information; if the value had been updated by another thread in the meantime, the write would fail. The result of the operation must indicate whether it performed the substitution; this can be done either with a simple boolean response, or by returning the value read from the memory location.

In computing, a memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier.

In computer programming, volatile means that a value is prone to change over time, outside the control of some code. Volatility has implications within function calling conventions, and also impacts how variables are stored, accessed and cached.

<span class="mw-page-title-main">Linearizability</span> Property of some operation(s) in concurrent programming

In concurrent programming, an operation is linearizable if it consists of an ordered list of invocation and response events, that may be extended by adding response events such that:

  1. The extended list can be re-expressed as a sequential history.
  2. That sequential history is a subset of the original unextended list.

In concurrent programming, a monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become false. Monitors also have a mechanism for signaling other threads that their condition has been met. A monitor consists of a mutex (lock) object and condition variables. A condition variable essentially is a container of threads that are waiting for a certain condition. Monitors provide a mechanism for threads to temporarily give up exclusive access in order to wait for some condition to be met, before regaining exclusive access and resuming their task.

Join Java is a programming language based on the join-pattern that extends the standard Java programming language with the join semantics of the join-calculus. It was written at the University of South Australia within the Reconfigurable Computing Lab by Dr. Von Itzstein.

In computer science, a readers–writer is a synchronization primitive that solves one of the readers–writers problems. An RW lock allows concurrent access for read-only operations, whereas write operations require exclusive access. This means that multiple threads can read the data in parallel but an exclusive lock is needed for writing or modifying data. When a writer is writing the data, all other writers and readers will be blocked until the writer is finished writing. A common use might be to control access to a data structure in memory that cannot be updated atomically and is invalid until the update is complete.

In computer science, synchronization refers to one of two distinct but related concepts: synchronization of processes, and synchronization of data. Process synchronization refers to the idea that multiple processes are to join up or handshake at a certain point, in order to reach an agreement or commit to a certain sequence of action. Data synchronization refers to the idea of keeping multiple copies of a dataset in coherence with one another, or to maintain data integrity. Process synchronization primitives are commonly used to implement data synchronization.

The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language.

In computing, a memory model describes the interactions of threads through memory and their shared use of the data.

In computer science, a concurrent data structure is a particular way of storing and organizing data for access by multiple computing threads on a computer.

A concurrent hash-trie or Ctrie is a concurrent thread-safe lock-free implementation of a hash array mapped trie. It is used to implement the concurrent map abstraction. It has particularly scalable concurrent insert and remove operations and is memory-efficient. It is the first known concurrent data-structure that supports O(1), atomic, lock-free snapshots.

The Java programming language's Java Collections Framework version 1.5 and later defines and implements the original regular single-threaded Maps, and also new thread-safe Maps implementing the java.util.concurrent.ConcurrentMap interface among other concurrent interfaces. In Java 1.6, the java.util.NavigableMap interface was added, extending java.util.SortedMap, and the java.util.concurrent.ConcurrentNavigableMap interface was added as a subinterface combination.

References

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.