• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Volatile boolean versus AtomicBoolean

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I use a shared flag between threads.Is an AtomicBolean faster than the volatile version?

Thanks
 
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would you really worry about the performance of updating/getting a boolean flag, whether it is volatile or Atomic?
I would use an AtomicBoolean if i want to use a compareAndSet() so that i can assure that i *only* set a value if it is equal to something.
However, i will use volatile if i want to make sure that while getting a value i get the latest. eg: if i have a thread that keeps on running till the *isRunning* flag is true. This qualifies for a volatile flag.
Having said the above, most of the methods of AtomicBoolean involves a native method call, so i think it will be costly, but i am really not sure.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A volatile boolean has less functionality than an AtomicBoolean (it has fewer operations that are defined as atomic actions), so I hope volatile is at least slightly faster, otherwise there is really no reason to ever use it. However I really doubt the performance difference matters much in most cases. Try using both and measuring the difference in performance. If you can't find a clear difference, it doesn't matter.

[Nitesh]: Having said the above, most of the methods of AtomicBoolean involves a native method call, so i think it will be costly, but i am really not sure.

Hm, I've heard that using JNI can introduce an overhead into method calls. But I wouldn't want people to avoid using any method defined as native because they heard it's "costly". Especially for classes built into the JDK; they have direct access to resources we outsiders don't. The classes in java.util.concurrent.atomic are supposed to offer better performance than synchronization, at least, for the more limited functionality they provide. Otherwise there would be no point in having the classes at all. Whether or not they're also faster than volatiles (with their even more limited functionality) I don't know.

Like most performance questions, the vast majority of the time it really doesn't matter anyway. And in those cases where it does seem to matter, you'll get a more reliable answer by trying it both ways and measuring the results.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with you Jim that the atomic package classes provide a better performance than synchronization. The reason *probably* being that i can find the following code in most of the *efficient* methods


the compareAndSet() method makes a native call to set the value to next if it was equal to current.
So, the locking will *probably* happen in the native code that *may* make it faster.
Anyways, going back to the question, i dont think it is worth comparing the performance between a volatile and AtomicBoolean as they are present for different and specific requirements. The javadoc for atomic package itself says that these should not be taken as a replacement for volatile.

But I wouldn't want people to avoid using any method defined as native because they heard it's "costly".


Agree, cost is only a concern when we can achieve the same functionality without this cost. If there is no alternative then this question should not come into picture at all.
 
reply
    Bookmark Topic Watch Topic
  • New Topic