Re: 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
> 
>