RE: volatile long

I'd just like to reinforce the message here as this is the second case of
this particular misunderstanding that has arisen in recent time.

The basic rules are:

1. reading or writing all 32-bit values is atomic
2. reading or writing all volatile variables is atomic
3. reading/writing volatile variables establishes specific happens-before
relationships in the memory model

volatile does not make any other operations other than a simple read or a
simple write, atomic.

While statements like v++ or --v could be implemented by a particular JVM on
a particular architecture using a single atomic update instruction, the
language itself provides no such guarantee. Indeed the semantics of ++/--
are that expressions using them yield a value and they are defined in terms
of a read-modify-write sequence. It would be a potential optimisation, in
the case where the value is not used, to perform an atomically updating
instruction, but not an optimisation that a program should ever rely upon.
If you always think of v++/v-- as syntactic shorthand for v=v+1, v=v-1 then
the read-modify-write semantics are more obvious.

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces@xxxxxxxxxxxxx
> [mailto:concurrency-interest-bounces@xxxxxxxxxxxxx]On Behalf Of Hanson
> Char
> Sent: Thursday, 17 February 2005 9:30 PM
> To: Joe Bowbeer
> Cc: concurrency-interest@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [concurrency-interest] volatile long
>
>
> Thanks Joe, I did some experiment and the result is on your side.  The
> ++count is a read-modify-write operation, not a pure write operation.
> So volatile will never work with such construct.
>
> Hanson
>
> On Thu, 17 Feb 2005 02:38:41 -0800, Joe Bowbeer <jozart@xxxxxxxxx> wrote:
> > A similar example is presented in the article "Going Atomic" by
> JSR-166 EG
> > member Brian Goetz:
> >
> > http://www-106.ibm.com/developerworks/java/library/j-jtp11234/
> >
> > where it clearly states that declaring the count variable
> "volatile" will
> > not solve the problem.
> >
> >
> > ----- Original Message -----
> > From: "Hanson Char" <hanson.char@xxxxxxxxx>
> > To: "Joe Bowbeer" <jozart@xxxxxxxxx>
> > Cc: <concurrency-interest@xxxxxxxxxxxxxxxxxxxx>
> > Sent: Thursday, February 17, 2005 2:05 AM
> > Subject: Re: [concurrency-interest] volatile long
> >
> > I just found out from the JLS 2ed, Section 17.7 (p 437):
> >
> > "The load, store, read and write actions on volatile variables are
> > atomic, even if the type of the variable is double or long"
> >
> > Hanson
> >
> > On Thu, 17 Feb 2005 01:10:43 -0800, Joe Bowbeer
> <jozart@xxxxxxxxx> wrote:
> > > Even though though ++ and -- are each represented by a single bytecode
> > > (iinc), I don't think these are atomic operations in terms of the JMM.
> > > That
> > > is, each is composed of a read followed by a write.  In which
> case, even
> > > an
> > > "int" count can creep very negative or very positive over
> time, depending
> > > on
> > > the interleaving of threads.  Use AtomicInteger to prevent
> counter creep.
> > >
> > > Volatile protects long values from word shearing, but it
> doesn't turn ++
> > > or -- into atomic operations either.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Hanson Char" <hanson.char@xxxxxxxxx>
> > > To: <concurrency-interest@xxxxxxxxxxxxxxxxxxxx>
> > > Sent: Thursday, February 17, 2005 12:49 AM
> > > Subject: [concurrency-interest] volatile long
> > >
> > > A question on the use of volatile in a concurrent environment.
> > > Consider the example:
> > >
> > > public class  Foo {
> > >     private volatile int count;
> > >
> > >      public void run() {
> > >         count++;
> > >         // ... do some other operations
> > >         count--;
> > >     }
> > >      public int getCount() { return count; }
> > > }
> > >
> > > My understanding is:
> > >
> > > 1) The value returned by getCount() will never be less than zero; and
> > > 2) count will never be in a corrupted state.
> > >
> > > Does the above 2 statements still hold if count is type long
> instead of
> > > int
> > > ?
> > >
> > > Hanson
> >
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@xxxxxxxxxxxxxxxxxxxx
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>