Atomic Operations in Java

Imagine two threads in one Java program. One thread sets a flag, and the other thread checks that flag over and over to decide when to stop working. The flag is shared data, and the obvious question is whether it needs protection. Synchronization is the usual tool for coordinating threads that touch shared data, but it has a real cost. Programmers are therefore tempted to skip it when they believe a simple read or write is harmless.

This article examines one specific case: when a shared variable can be used safely without synchronization, and what the volatile keyword does to make that possible. It also covers a second topic that appears in the same course material, the arithmetic operators of Java, because arithmetic results depend on both the operator and the types of the operands.

Threads in Java are allowed to cache shared data. Each thread may keep its own local copy of a shared variable. When one thread changes the variable, the copies held by other threads are not updated right away. A thread reading from its local copy can therefore keep seeing the old value for some time, even though another thread has already written a new one.

The stale value is a visibility problem. It is distinct from the timing problems that synchronization addresses. The issue is not that two threads run at the same moment and collide. The issue is that a change made in one thread may not reach the other in time to matter. The source describes this as a subtle problem that arises when a value is set in one thread and used in another.

Declaring a variable volatile makes changes to it immediately visible to all threads, because no thread keeps a private cached copy. The source explains that this is what makes it safe for threads to refer to volatile shared variables even outside of synchronized code. The keyword is placed on the declaration of a variable that several threads can reach, such as a field of an object shared between them.

In this flag example, the volatile keyword addresses exactly the problem described earlier. Once one thread sets stopRequested to true, the other thread's loop is able to see that change without waiting for a stale copy to be refreshed. Volatile solves visibility for this single flag. It does not, by itself, make every operation on shared data safe, as the next section shows.

Volatile solves visibility, but not every problem with shared data. The source gives a direct example: an increment on a variable can still be interrupted by another thread, even if that variable is volatile. An increment is not a single step. It is a read, then an add, then a write. Another thread can run between those steps, so two threads may read the same starting value and both write back the same result. Volatile does not prevent that interleaving.

Both approaches let threads share data safely in some situations, but they do different jobs and cost different amounts. The source states that synchronization is fairly expensive computationally and that excessive use should be avoided. It also states that access to volatile variables is less efficient than access to non-volatile variables, but more efficient than using synchronization.

When Java evaluates an arithmetic expression, it must determine both which operation to perform and what types the operands should have while performing it. The operators look familiar from mathematics. The basic binary operators are addition (+), subtraction (-), multiplication (*), division (/), and remainder (%). Unlike the others in this list, the remainder operator is covered in its own section below because its meaning is easy to misread.

The operand types can change the result, especially with division. The rest of this article shows why an expression such as 7 / 2 can give a different answer from 7 / 2.0, and how Java decides what type a mixed expression should use.

Division follows the type of its operands. Two integer operands produce an integer result, even when ordinary mathematical division would include a fractional part. If at least one operand is a real number, Java converts the other operand to a real number and produces a real-number result. Integer division discards the fractional part, while a real operand causes real-number division.

Suppose an expression combines values whose types differ. Before carrying out the operation, Java converts one value so that the two operands match. This automatic adjustment is called type conversion. The source gives the example 37.4 + 10. The integer 10 is converted to the real number 10.0, and Java then evaluates the operation using 37.4 and 10.0.

The percent sign, %, does not mean percentage in this context. It gives what remains after one number is divided by another. For integer operands, 7 % 2 is 1, 34577 % 100 is 77, and 50 % 8 is 2. Each of these is the leftover after the whole-number division has been carried out.

Most arithmetic operators combine two values. Unary operators are different because they act on one operand. Unary minus changes a number to its negative: -X has the same value as (-1) * X. Unary plus is also available, but +X leaves the value of X unchanged.

The plus operator has a second role in Java. When one side of the operation is a String, + concatenates the value onto that text instead of performing numeric addition. The other value is automatically converted to a String for this combination. Java decides at each step of an expression whether the + it reaches is numeric addition or text joining, based on the operands present at that step.