explaining the process take makes the lack of synchronization here fails

[fabrulous]

Hi everybody,

I'm interested in knowing why the following is wrong. I know it is
wrong, I'm no looking for a "correct" way to do the following (Joshua
Bloch and Doug Lea already taught me that [no I don't know
them]

So this is wrong "on purpose", to try to understand what's going on
behind the scene.

Here's the wrong code:

public class A {
public static int global = 42; // ugly code isn't it
}

Now here's what I'm doing really wrong: I'm accessing
and changing that "global" from a lot of threads, without any
"synchronization". I know this is bad. I make it on purpose,
to try to understand what's going on.

Now I've got lots of questions to try to understand all this better...

On a 32-bit JVM, is atomicity guaranteed ? I mean: I am guaranteed
to always read a value that was actually written in that global int by
another thread or is it possible to read my int in an inconsistent
state?

Am I guaranteed to always read the latest value that has been written
in that global int by any thread (I understand the answer is "no" but I
may
be confused) ?

If some thread may be reading old values, where do they come from?

On a 32-bit JVM, if I do the same with a *long*, is atomicity
guaranteed
for the long?

And now a though one (to grasp for me): is it possible, on a 32-bit
JVM,
to have atomicity of a *long* guaranteed, but no guarantee made as
to which value would a thread actually read? If so, how could one
achieve such an horror?

For example:
-at t0 thread A writes 1111111111111111 (hex) in a long
-at t1 thread B writes 2222222222222222 (hex) in that "same" long
-at t3 thread C reads 1111111111111111 (hex) from that "same" long

How could that happen, while making sure not a single thread ever
reads "1111111122222222" (or 2222222211111111) ? Note that I do
not want to do this, I want to know if it's possible to have the long
always read in a consistent state, while still having the possibility
for a thread to read an "old" value that was in the long.



And lastly, isn't AtomicBoolean actually a misnomer? How could you
read a boolean and have something else than 0 or 1? How could a
boolean be in an inconsistent state?

I know that the AtomicBoolean is actually implemented by
using the volatile keyword, but volatile or not, I don't understand
how a boolean could be in an inconsistent state.

Seen that there are no 16-bit JVM (are there?), AtomicInteger
seems strange too.

But then probably it's just my definition of "atomic" that is wrong
(after all the very definition of "atom" back in the days was quite
wrong

If so, what is the name you give to an operation that guarantees
that you won't observe a "value" in an inconsistent state (Java or
other languages)?

Any light on this greatly appreciated and any gory details about
memory, caching, registers, stacks (if any of this related to the
question) etc. greatly appreciated,

fab

 

[Chris Uppal]

On a 32-bit JVM, is atomicity guaranteed ? I mean: I am guaranteed
to always read a value that was actually written in that global int by
another thread or is it possible to read my int in an inconsistent
state?

Yes. Or on any other JVM -- that atomicity is part of the language spec.

Am I guaranteed to always read the latest value that has been written
in that global int by any thread (I understand the answer is "no" but I
may be confused) ?

No there is definitely no such guarantee.

If some thread may be reading old values, where do they come from?

Some possible answers:
-- the stale value is in the CPU's internal caches
-- the new value is in memory associated with one processor
which has not yet been propagated to the memory seen
by another processor.
-- the JIT/compiler has generated code to make and use a copy
of the value in A.global instead of going back to the "real"
field on each access.

On a 32-bit JVM, if I do the same with a *long*, is atomicity
guaranteed for the long?

No. Again this is part of the JLS, nothing to do with the 32-bitness of the
JVM.

And now a though one (to grasp for me): is it possible, on a 32-bit
JVM,
to have atomicity of a *long* guaranteed, but no guarantee made as
to which value would a thread actually read? If so, how could one
achieve such an horror?

I imagine that could be possible if the real CPU and memory system was capable
of issuing 64-bit reads and writes, if the CPU/memory is such that it offers
stronger atomicity guarantees than are required for a conforming JVM, and if
the JIT generated code to take advantage of that. If so then reads/writes
could never "see" invented values, but stale data could still be lurking in the
system's caches and whatnot. Note, though, that this would be an "accidental"
property of the implementation, not something that is guaranteed by the
language.

I could easily be wrong, but I /suspect/ that a current JVM running on a 32-bit
P4 has that property. Please don't take that as any kind of an expert opinion
! It's more an invitation for someone to explain that I'm wrong (again).

And lastly, isn't AtomicBoolean actually a misnomer? How could you
read a boolean and have something else than 0 or 1? How could a
boolean be in an inconsistent state?

I think the "atomic" part of the name refers to the atomic test-and-set
operations rather than to any indivisibility of the value itself. Similarly
for the other "atomic" classes.

-- chris

 

[Thomas Hawtin]

I think the "atomic" part of the name refers to the atomic test-and-set
operations rather than to any indivisibility of the value itself. Similarly
for the other "atomic" classes.

Indeed. According to the spec, volatile is enough to ensure atomic read
and writes for longs and doubles. The AtomicXxxFieldUpdater classes
would be pointless without atomic operations.

A common mistake is to assume that ++ will work atomically on volatile
variables. ++a; is equivalent to a = a + 1; and is not atomic.

Tom Hawtin