Atomic thread safe integer increment..

Discussion in 'Java' started by lordy, Sep 14, 2006.

  1. lordy

    lordy Guest

    Hi, I want to keep a running 'int' total across threads but without the
    'synchronized' overhead. (This total will be spinning pretty fast).

    I'm guessing Most processors have some kind of atomic (and hopefully) thread safe increment command.
    However a big of Googling suggests this may be possible in Java 1.5 but
    not in Java 1.4.2 ('Twas an IBM article http://www-128.ibm.com/developerworks/java/library/j-jtp11234/)

    I guess the most performant(?) option is to maintain separate totals and
    combine them at report time?

    Lordy
    lordy, Sep 14, 2006
    #1
    1. Advertising

  2. On 14.09.2006 14:04 lordy wrote:
    > Hi, I want to keep a running 'int' total across threads but without the
    > 'synchronized' overhead. (This total will be spinning pretty fast).
    >
    > I'm guessing Most processors have some kind of atomic (and hopefully) thread safe increment command.
    > However a big of Googling suggests this may be possible in Java 1.5 but
    > not in Java 1.4.2 ('Twas an IBM article http://www-128.ibm.com/developerworks/java/library/j-jtp11234/)
    >
    > I guess the most performant(?) option is to maintain separate totals and
    > combine them at report time?
    >


    The perfomance "penalty" of a synchronized block is relatively small.

    I think there is an article on DeveloperWorks that de-mystifies the
    common believe that synchronize will make things slower. If I recall the
    article correctly this was true for JDK up to 1.3 but starting with 1.4
    (or 1.5 not 100% sure about that) the overhead is so small that it does
    not justify the effort to avoid it.

    Thomas


    --
    It's not a RootKit - it's a Sony
    Thomas Kellerer, Sep 14, 2006
    #2
    1. Advertising

  3. Thomas Kellerer wrote:
    > On 14.09.2006 14:04 lordy wrote:
    >> Hi, I want to keep a running 'int' total across threads but without the
    >> 'synchronized' overhead. (This total will be spinning pretty fast).


    >> I guess the most performant(?) option is to maintain separate totals and
    >> combine them at report time?
    >>

    >
    > The perfomance "penalty" of a synchronized block is relatively small.
    >
    > I think there is an article on DeveloperWorks that de-mystifies the
    > common believe that synchronize will make things slower. If I recall the
    > article correctly this was true for JDK up to 1.3 but starting with 1.4
    > (or 1.5 not 100% sure about that) the overhead is so small that it does
    > not justify the effort to avoid it.


    If it's a contended lock, particularly on a multicore machine, it could
    well be a problem. Having said that, in this case the lock shouldn't be
    held for very long.

    A local value for each thread should be much faster. Alternatively, if
    you can live with an inaccurate variable, just use volatile (I think
    that works in 1.4).

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Sep 14, 2006
    #3
  4. Thomas Kellerer wrote:
    > On 14.09.2006 14:04 lordy wrote:
    >> Hi, I want to keep a running 'int' total across threads but without the
    >> 'synchronized' overhead. (This total will be spinning pretty fast).
    >>
    >> I'm guessing Most processors have some kind of atomic (and hopefully)
    >> thread safe increment command.
    >> However a big of Googling suggests this may be possible in Java 1.5 but
    >> not in Java 1.4.2 ('Twas an IBM article
    >> http://www-128.ibm.com/developerworks/java/library/j-jtp11234/)
    >>
    >> I guess the most performant(?) option is to maintain separate totals and
    >> combine them at report time?
    >>

    >
    > The perfomance "penalty" of a synchronized block is relatively small.
    >
    > I think there is an article on DeveloperWorks that de-mystifies the
    > common believe that synchronize will make things slower. If I recall the
    > article correctly this was true for JDK up to 1.3 but starting with 1.4
    > (or 1.5 not 100% sure about that) the overhead is so small that it does
    > not justify the effort to avoid it.

    ....

    There is an inherent cost to synchronization in forcing threads to run
    serially rather than in parallel, but you would have to be doing a
    simple integer increment very, very frequently relative to other work
    before that would be a problem.

    The usual advice, start simple and optimize if necessary, applies.

    Patricia
    Patricia Shanahan, Sep 14, 2006
    #4
    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. Replies:
    6
    Views:
    10,349
    Walter Roberson
    Mar 26, 2006
  2. Replies:
    0
    Views:
    286
  3. Mark Thornton

    Re: is assignment atomic/thread safe?

    Mark Thornton, Feb 20, 2009, in forum: Java
    Replies:
    24
    Views:
    2,142
    Arne Vajhøj
    Feb 21, 2009
  4. Tom Anderson

    Re: is assignment atomic/thread safe?

    Tom Anderson, Feb 20, 2009, in forum: Java
    Replies:
    5
    Views:
    670
    Mark Space
    Feb 22, 2009
  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:
    211
    Robert Dober
    Jun 8, 2010
Loading...

Share This Page