Volatile boolean vs AtomicBoolean

Question

What does AtomicBoolean do that a volatile boolean cannot achieve

User · Answer

Remember the IDIOM -  READ - MODIFY- WRITE this you can t achieve with volatile

User · Answer

If you have only one thread modifying your boolean  you can use a volatile boolean  usually you do this to define a stop variable checked in the thread s main loop    However  if you have multiple threads modifying the boolean  you should use an AtomicBoolean  Else  the following code is not safe   boolean r    myVolatileBoolean    This operation is done in two steps    The boolean value is read  The boolean value is written    If an other thread modify the value between  1 and 2   you might got a wrong result  AtomicBoolean methods avoid this problem by doing steps  1 and  2 atomically

User · Answer

Boolean primitive type is atomic for write and read operations  volatile guarantees the happens-before principle  So if you need a simple get   and set   then you don t need the AtomicBoolean   On the other hand if you need to implement some check before setting the value of a variable  e g   if true then set to false   then you need to do this operation atomically as well  in this case use compareAndSet and other methods provided by AtomicBoolean  since if you try to implement this logic with volatile boolean you ll need some synchronization to be sure that the value has not changed between get and set

User · Answer

Both are of same concept but in atomic boolean it will provide atomicity to the operation in case the cpu switch happens in between

User · Answer

AtomicBoolean has methods that perform their compound operations atomically and without having to use a synchronized block  On the other hand  volatile boolean can only perform compound operations if done so within a synchronized block   The memory effects of reading writing to volatile boolean are identical to the get and set methods of AtomicBoolean respectively   For example the compareAndSet method will atomically perform the following  without a synchronized block    if  value    expectedValue        value   newValue      return true    else       return false      Hence  the compareAndSet method will let you write code that is guaranteed to execute only once  even when called from multiple threads  For example   final AtomicBoolean isJobDone   new AtomicBoolean false         if  isJobDone compareAndSet false  true         listener notifyJobDone        Is guaranteed to only notify the listener once  assuming no other thread sets the AtomicBoolean back to false again after it being set to true

User · Answer

You can t do compareAndSet  getAndSet as atomic operation with volatile boolean  unless of course you synchronize it

User · Answer

They are just totally different  Consider this example of a volatile integer   volatile int i   0  void incIBy5         i    5      If two threads call the function concurrently  i might be 5 afterwards  since the compiled code will be somewhat similar to this  except you cannot synchronize on int    void incIBy5         int temp      synchronized i    temp   i       synchronized i    i   temp   5       If a variable is volatile  every atomic access to it is synchronized  but it is not always obvious what actually qualifies as an atomic access  With an Atomic  object  it is guaranteed that every method is  atomic     Thus  if you use an AtomicInteger and getAndAdd int delta   you can be sure that the result will be 10  In the same way  if two threads both negate a boolean variable concurrently  with an AtomicBoolean you can be sure it has the original value afterwards  with a volatile boolean  you can t    So whenever you have more than one thread modifying a field  you need to make it atomic or use explicit synchronization   The purpose of volatile is a different one  Consider this example  volatile boolean stop   false  void loop         while   stop            void stop     stop   true      If you have a thread running loop   and another thread calling stop    you might run into an infinite loop if you omit volatile  since the first thread might cache the value of stop  Here  the volatile serves as a hint to the compiler to be a bit more careful with optimizations

User · Answer

If there are multiple threads accessing class level variable then each thread can keep copy of that variable in its threadlocal cache   Making the variable volatile will prevent threads from keeping the copy of variable in threadlocal cache   Atomic variables are different and they allow atomic modification of their values

User · Answer

Volatile boolean vs AtomicBoolean  The Atomic  classes wrap a volatile primitive of the same type  From the source  public class AtomicLong extends Number implements java io Serializable             private volatile long value            public final long get            return value                 public final void set long newValue           value   newValue        So if all you are doing is getting and setting a Atomic  then you might as well just have a volatile field instead   What does AtomicBoolean do that a volatile boolean cannot achieve   Atomic  classes give you methods that provide more advanced functionality such as incrementAndGet   for numbers  compareAndSet   for booleans  and other methods that implement multiple operations  get increment set  test set  without locking  That s why the Atomic  classes are so powerful  For example  if multiple threads are using the following code using     there will be race conditions because    is actually  get  increment  and set  private volatile value         race conditions here value     However  the following code will work in a multi-threaded environment safely without locks  private final AtomicLong value   new AtomicLong        value incrementAndGet     It s also important to note that wrapping your volatile field using Atomic  class is a good way to encapsulate the critical shared resource from an object standpoint  This means that developers can t just deal with the field assuming it is not shared possibly injecting problems with a field    or other code that introducing race conditions

User · Answer

volatile keyword guarantees happens-before relationship among threads sharing that variable  It doesn t guarantee you that 2 or more threads won t interrupt each other while accessing that boolean variable

User · Answer

I use volatile fields when said field is ONLY UPDATED by its owner thread and the value is only read by other threads  you can think of it as a publish subscribe scenario where there are many observers but only one publisher  However if those observers must perform some logic based on the value of the field and then push back a new value then I go with Atomic  vars or locks or synchronized blocks  whatever suits me best  In many concurrent scenarios it boils down to get the value  compare it with another one and update if necessary  hence the compareAndSet and getAndSet methods present in the Atomic  classes    Check the JavaDocs of the java util concurrent atomic package for a list of Atomic classes and an excellent explanation of how they work  just learned that they are lock-free  so they have an advantage over locks or synchronized blocks

[java] Volatile boolean vs AtomicBoolean

Examples related to java

Examples related to concurrency

Examples related to boolean

Examples related to volatile

Examples related to atomicboolean