views:

87

answers:

4

Is correct to divide the following statements:

int v = ++j;

as:

  1. read j value (atomic);
  2. increment by 1 the value read (NON atomic possibly interference by other thread);
  3. write the adding result to i (atomic);
  4. write i into v (atomic)
A: 

I would use AtomicInteger

AtomicInteger j; // do init

int v = j.incrementAndGet();

A quick view with JAD shows the following byte code for the instructions:

    int j = 0;
//    0    0:iconst_0
//    1    1:istore_1
    int v = ++j;
//    2    2:iinc            1  1
//    3    5:iload_1
//    4    6:istore_2
stacker
Yes, thanks, but I wish to know only if the JVM divides the above operations as I wrote.
xdevel2000
+1  A: 

Close. Step 2 is atomic. In this case j must be one of byte, char, short or int, and each of these can be loaded and stored atomically.

Once a value has been loaded into a hardware register, there should be no possibility that another thread can interfere with it. There's probably something in the JLS about the atomicity of primitive operations ... but I cannot spot it.

Stephen C
Or `double`. (And not `volatile`.) In the example code it can't be `long` or `double`.
Tom Hawtin - tackline
Step 2 is atomic? Why? In many books I read that only read/write operations are atomic!
xdevel2000
@xdevel2000 Looking back at the (current) question steps 1 and 3 could sheer with different datatypes.
Tom Hawtin - tackline
@xdevel2000: In step 2 the loaded value is incremented. It's atomic (or maybe the term atomic just doesn't apply here) because the loaded value is local to the thread, so no other can modify it. (but another thread may do the read before the first thread does the write, so an increment may still be skipped)
Bart van Heukelom
+4  A: 

Yes, int (or smaller datatypes) read/write/arithmetic operations are atomic. References (read/write) are also atomic, regardless of whether it's 32-bit or 64-bit.

However, operations on 64-bit long and double may not be atomic.

JLS 17.7 Non-atomic Treatment of double and long

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64 bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values.

VM implementors are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

Note that neither pre- nor post- increment/decrement operators themselves are atomic, not even on int or byte: the read/write/arithmetic operations happens in distinctly separate steps.

See also

polygenelubricants
See also JLS guarantee against Word Tearing http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.6
polygenelubricants
Thanks, but again really I don't understand if step 2 is atomic or not. You and others, it seems, say not while Stephen say yes. I'm confused. My be i++ as whole is considered not atomic while all the divided sub-operations are atomic (including increment)????
xdevel2000
@xdevel2000: what really matters is the atomicity of the reads and writes. `i++` may consist of an atomic read, followed by an atomic write, but as a whole is not one atomic "read-add-write" operation.
polygenelubricants
+1  A: 

Yes, your assumption is correct. Incrementing an int results in three steps (thus it is not atomic), assigning it is another step. Here is the resulting bytecode:

..
istore_1
iinc    1, 1
iload_1
istore_2
..
bunting