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