This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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.
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’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com