Clean Code

Calculating the Possible Orderings (continued)

---

324
Appendix A: Concurrency II
01: public class Example {
02: int lastId;
03:
04: public void resetId() {
05: value = 0;
06: }
07: 
08: public int getNextId() {
09: ++value;
10: }
11:}
What happens if we change type of 
lastId
from 
int
to 
long
? Is line 5 still atomic?
Not according to the JVM specification. It could be atomic on a particular processor,
but according to the JVM specification, assignment to any 64-bit value requires two
32-bit assignments. This means that between the first 32-bit assignment and the second
32-bit assignment, some other thread could sneak in and change one of the values. 
What about the pre-increment operator, ++, on line 9? The pre-increment operator can
be interrupted, so it is not atomic. To understand, let’s review the byte-code of both of these
methods in detail. 
Before we go any further, here are three definitions that will be important:
•
Frame—Every method invocation requires a frame. The frame includes the return 
address, any parameters passed into the method and the local variables defined in the 
method. This is a standard technique used to define a call stack, which is used by 
modern languages to allow for basic function/method invocation and to allow for 
recursive invocation.
•
Local variable—Any variables defined in the scope of the method. All nonstatic meth-
ods have at least one variable,
 
this
, which represents the current object, the object 
that received the most recent message (in the current thread), which caused the 
method invocation.
•
Operand stack—Many of the instructions in the Java Virtual Machine take parame-
ters. The operand stack is where those parameters are put. The stack is a standard 
last-in, first-out (LIFO) data structure.
Here is the byte-code generated for 
resetId()
: