0

I am setting a flag which is set once by any thread that get to set it. All other threads will at various time, pretty often read this flag repeateadly.

Right now I am using an AtomicBoolean, which works fine, but I know that if it is queried quite often it can be considerably slower than plain boolean, ( not sure if this is true ).

Would it be thread safe to instead change this to a static boolean? Set the flag to true by whoever gets to do that, in fact all of them might be allowed to set the flag several times over.

What I am concerned about is how quickly those reading the flag will be able to spot it? Will it be right of? Or might them not get it right?

Also, how big is the performance hit of using an AtomicBoolean that is queried often?

Also, should I perhaps consider using a volatile boolean over AtomicBoolean since I will pretty much only be setting it once and reading it, and can perform the set operation atomically ( copying the code in AtomicBoolean for getAndSet())

Cœur
  • 37,241
  • 25
  • 195
  • 267
mjs
  • 21,431
  • 31
  • 118
  • 200
  • 4
    Other threads might never see the new value of the boolean if it's not synchronized in some way (volatile, AtomicBoolean, or synchronized). Use AtomicBoolean, and only optimize if you have a performance problem, have measured it, and proven the performance comes from there. There's 99.999% chance it won't happen. And if it happens, you'll have to change the design, not simply choose another type for the variable. – JB Nizet Feb 08 '15 at 18:43

3 Answers3

4

When most of the threads only reads the variable and only one of them and once will change the value you don't need to worry about the performance. AtomicBoolean is using a mechanism called CAS which now is supported by most modern processors and is a low level operation. As a result of using CAS there is almost no drawback when reading the value (which is something different from using a standard lock). With the scenario you described volatile static boolean will be enough - volatile prevents jvm from doing optimization when reading from variable, like reusing value held in register instead of checking the value in memory, so whenever a thread change the value of variable other threads will see the change. In your case both solutions will give similar if not the same performance results. Volatile will be faster than AtomicBoolean in a scenario where lot of write operation have place, but honestly I can not imagine a scenario where you have lot of writing and no one is interested in reading.

enterbios
  • 1,725
  • 12
  • 13
2

If one thread sets the value and others read it, then volatile works fine.

If many threads may set it to true and you don't care which one actually does it, and then other thread only read it, volatile also works fine.

If many threads may set it true/false, then atomic, or synchronized, or some lock structure is the only way.

Yes, there is a performance issue with atomic, synchronized, etc. But safety usually outweighs this.

edharned
  • 1,884
  • 1
  • 19
  • 20
1

If the variable is set only once by any thread and never changes later, you can use conditional synchronized block for gaining some performance by eliminating unnecessary synchronized calls.

BUT I don't think that it worths to do. Just use AtomicBoolean or volatile variable.

public class Sandbox1 {
    private boolean status;

    public void setStatus(boolean status) {
        if (!this.status) {
            synchronized (this) {
                this.status = status;
            }
        }
    }

    public boolean isStatus() {
        if (!this.status) {
            synchronized(this) {
                return this.status;
            }
        }
        return this.status;
    }
}
Onur Aktaş
  • 410
  • 4
  • 8