Re: volatile long

JLS 2nd ed Section 8.3.1.4 (p.157):

"A field may be decalred volatile, in which case a thread must
reconcile its working copy of the field with the master copy every
time it accesses the variable.  Moreover, operations on the master
copies of one or more volatile variables on behalf of a thread are
performed by the main memory in exactly the order that the thread
requested."

>From this, it appears that the two statements 

> > 1) The value returned by getCount() will never be less than zero; and
> > 2) count will never be in a corrupted state.

are always true even if count is volatile long or volatile double.

Hanson

On Thu, 17 Feb 2005 21:05:49 +1100, Hanson Char <hanson.char@xxxxxxxxx> wrote:
> 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
> >
> >
>