Re: volatile long

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