• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Volatile boolean versus AtomicBoolean

 
Amit A. Patil
Ranch Hand
Posts: 38
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I use a shared flag between threads.Is an AtomicBolean faster than the volatile version?

Thanks
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • 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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • 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 Java MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • 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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic