Atomic operation and volatile variables

Discussion in 'Java' started by Sumukh, Sep 23, 2005.

  1. Sumukh

    Sumukh Guest

    Hi ,
    I have one volatile variable declared as

    private volatile long _volatileKey=0;

    This variable is being incremented(++_volatileKey) by a method which is
    not synchronized. Could there be a problem if more than one thread tries
    to change the variable ?
    In short is ++ operation atomic in case of volatile variables ?

    Thanks

    Sumukh
    Sumukh, Sep 23, 2005
    #1
    1. Advertising

  2. Sumukh

    Skip Guest

    "Sumukh" <> wrote in message
    news:1127479330.108250@sj-nntpcache-3...
    > Hi ,
    > I have one volatile variable declared as
    >
    > private volatile long _volatileKey=0;
    >
    > This variable is being incremented(++_volatileKey) by a method which is
    > not synchronized. Could there be a problem if more than one thread tries
    > to change the variable ?
    > In short is ++ operation atomic in case of volatile variables ?


    It's not atomic on my system, so it's not optimized away by the VM.

    My test was like this:


    private volatile int inc = 0;
    private final int loops = 1024 * 1024 * 8;

    public void run(){
    for (int i = 0; i < loops; i++)
    value++;
    }

    // later in the app
    System.out.println("expected: " + (loops * threads));
    System.out.println("value: " + value);

    When I run this app several times, inc always has another value.
    expected: 134217728
    current: 78678507
    So rougly half of the incs got mangled when running 16 threads.

    HTH
    Skip, Sep 23, 2005
    #2
    1. Advertising

  3. Skip coughed up:
    > "Sumukh" <> wrote in message
    > news:1127479330.108250@sj-nntpcache-3...
    >> Hi ,
    >> I have one volatile variable declared as
    >>
    >> private volatile long _volatileKey=0;
    >>
    >> This variable is being incremented(++_volatileKey) by a method
    >> which is not synchronized. Could there be a problem if more than one
    >> thread tries to change the variable ?
    >> In short is ++ operation atomic in case of volatile variables ?

    >
    > It's not atomic on my system, so it's not optimized away by the VM.
    >
    > My test was like this:
    >
    >
    > private volatile int inc = 0;
    > private final int loops = 1024 * 1024 * 8;
    >
    > public void run(){
    > for (int i = 0; i < loops; i++)
    > value++;
    > }
    >
    > // later in the app
    > System.out.println("expected: " + (loops * threads));
    > System.out.println("value: " + value);
    >
    > When I run this app several times, inc always has another value.
    > expected: 134217728
    > current: 78678507
    > So rougly half of the incs got mangled when running 16 threads.


    Interesting test. I've performed almost identical tests before myself, but
    for differing objectives: teaching synchronization fundamentals.

    Can you supply the /entire/ set of sources? I've got a morbid curiosity to
    see if there is a mistake in there (I strongly doubt it, don't get me wrong,
    but want to see what your test was /precisely/ "just in case"----please take
    no offense, and feel free to ignore me with certainly no grumbling on my
    part whatsoever ) . Thanks!

    --
    Forgetthesong,I'dratherhavethefrontallobotomy...
    Thomas G. Marshall, Sep 23, 2005
    #3
  4. Sumukh

    Chris Uppal Guest

    Sumukh wrote:

    > In short is ++ operation atomic in case of volatile variables ?


    No. Not by definition; though I suppose it might happen to be "atomic" on some
    particular combinations of machine architecture and code-generation strategy.

    -- chris
    Chris Uppal, Sep 23, 2005
    #4
  5. Thomas Hawtin, Sep 23, 2005
    #5
  6. Sumukh wrote:

    > In short is ++ operation atomic in case of volatile variables ?


    OP posted the same question here:
    <http://forum.java.sun.com/thread.jspa?threadID=666377>
    Thomas Schodt, Sep 23, 2005
    #6
  7. Thomas Hawtin coughed up:
    > Sumukh wrote:
    >>
    >> In short is ++ operation atomic in case of volatile variables ?

    >
    > No.
    >
    > If you are using 1.4 or earlier, you need to switch the volatile to
    > synchronisation, at least for *all* updates (including the first).
    > From 5.0 use this:
    >
    > http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.html
    >
    > Tom Hawtin



    Yep. Or you can create something that is an extension of Number in the
    first place:

    http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/AtomicInteger.html

    If that is more appropos to your situation. Tom's Hawtin's suggestion is
    the most likely to be useful though IMO.



    --
    "It's easier to be terrified by an enemy you admire."
    -Thufir Hawat, Mentat and Master of Assassins to House Atreides
    Thomas G. Marshall, Sep 23, 2005
    #7
  8. Sumukh

    Skip Guest

    "Thomas G. Marshall" <>
    wrote in message news:XbUYe.5$lP3.0@trndny08...
    > Skip coughed up:
    > > "Sumukh" <> wrote in message
    > > news:1127479330.108250@sj-nntpcache-3...
    > >> Hi ,
    > >> I have one volatile variable declared as
    > >>
    > >> private volatile long _volatileKey=0;
    > >>
    > >> This variable is being incremented(++_volatileKey) by a method
    > >> which is not synchronized. Could there be a problem if more than one
    > >> thread tries to change the variable ?
    > >> In short is ++ operation atomic in case of volatile variables ?

    > >
    > > It's not atomic on my system, so it's not optimized away by the VM.
    > >
    > > My test was like this:
    > >
    > >
    > > private volatile int inc = 0;
    > > private final int loops = 1024 * 1024 * 8;
    > >
    > > public void run(){
    > > for (int i = 0; i < loops; i++)
    > > value++;
    > > }
    > >
    > > // later in the app
    > > System.out.println("expected: " + (loops * threads));
    > > System.out.println("value: " + value);
    > >
    > > When I run this app several times, inc always has another value.
    > > expected: 134217728
    > > current: 78678507
    > > So rougly half of the incs got mangled when running 16 threads.

    >
    > Interesting test. I've performed almost identical tests before myself,

    but
    > for differing objectives: teaching synchronization fundamentals.
    >
    > Can you supply the /entire/ set of sources? I've got a morbid curiosity

    to
    > see if there is a mistake in there (I strongly doubt it, don't get me

    wrong,
    > but want to see what your test was /precisely/ "just in case"----please

    take
    > no offense, and feel free to ignore me with certainly no grumbling on my
    > part whatsoever ) . Thanks!


    Well, I'm using quite a bit of classes to reduce the typing. It basicly
    waits until all 16 threads are running, only then feeding them the same
    Runnable at the same time, so have as much collisions as possible.. Without
    a doubt the classes have dependecies to other classes etc etc etc. Basily
    the code just does what's visible in the code that I already supplied, just
    in a fancy shell. I'd hate to dump all sources on usenet, not only because
    it's messy, but also because it contains lots of stuff that's not meant to
    be public, yet.

    Just try to imagine I did "new Thread(this).start()" 16 times and you have
    basicly the same :eek:)
    Skip, Sep 23, 2005
    #8
  9. Sumukh

    Roedy Green Guest

    On Fri, 23 Sep 2005 16:26:05 +0100, "Chris Uppal"
    <-THIS.org> wrote or quoted :

    >No. Not by definition; though I suppose it might happen to be "atomic" on some
    >particular combinations of machine architecture and code-generation strategy.


    Consider this snippet of code:
    public class VolatileTest
    {
    private static volatile long key=0;

    public static void main ( String[] args )
    {
    key++;
    }
    }

    if you compile it and disassemble it with javap -c VolatileTest
    you will see the ++ increment is implemented with four JVM
    instructions:


    getstatic #2; //Field key:J
    lconst_1
    ladd
    putstatic #2; //Field key:J


    That means it is most certainly not atomic.

    However, on an Intel machine an optimising compiler or AOT compiler
    might coalesce that like this:

    inc key[ebx]

    which would be atomic at least on a single CPU machine.


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 23, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kashish
    Replies:
    1
    Views:
    342
    msalters
    May 27, 2005
  2. Paul Moore
    Replies:
    5
    Views:
    313
    Parzival
    Nov 15, 2003
  3. Atomic Operation

    , Aug 27, 2006, in forum: Java
    Replies:
    3
    Views:
    452
  4. ben
    Replies:
    5
    Views:
    595
    Ulrich Eckhardt
    Jan 11, 2005
  5. Charles Oliver Nutter

    [ANN] atomic 0.0.1 - An atomic reference for Ruby

    Charles Oliver Nutter, Jun 8, 2010, in forum: Ruby
    Replies:
    5
    Views:
    229
    Robert Dober
    Jun 8, 2010
Loading...

Share This Page