Is getter method an alternative to volatile in Java?

Question

I'm wondering if a getter method for a private boolean field forces the other threads to get the latest updated value? Is this an alternative for volatile field? For example:

Class A {
    private boolean flag;

    public boolean getFlag() {
        return this.flag;
    }

    public void setFlag(boolean flag) {
        this.flag = flag;
    }
}

vs

Class B {
    public volatile boolean flag;
}

Edit: Is it true that the entire object is cached by a thread (including the private field), so that when I call the getter it will return the cached private field?

Eslinger

No. These two are in no way equivalent. Why would you think that they are? Logically; if volatile were the same as a getter then why would we need an entirely new language keyword for it? – Sink

As I said, I think the getter forces a thread to get an uncached value. Why isn't a getter taking the last updated value? – Eslinger

Maybe you need to see JLS. – Francesfrancesca

"I think the getter forces a thread to get an uncached value." What makes you think that? Do you have any reference for it? I'm not aware of anything along those lines. – Fredericfrederica

@ovidiu-miu if every reference to a local variable from a method caused a full cache miss to main memory (i.e. a memory barrier) then Java would not be a very efficient language. It would, in fact, be up to 300(!) times slower than it currently is... – Sink

Why would a getter take the value from cache, and not rather from the 'source'? – Eslinger

For the same reason any other method would read from a cache: to be more efficient. 99.99% of the variables are accessed by a single thread. When they are not, you need to apply proper synchronization to access them. Volatile is one of those synchronization techniques. – Guadalupeguadeloupe

Because reading from CPU cache is the default - special instructions have to be inserted to force synchronization – Hammer

You are asking the equivalent of "are curtains an alternative to a table?" They're not even remotely related. – Hellgrammite

@JoeC Not really. Maybe the question is too subtle. – Eslinger

@JoeC isn't far off. Hopefully the answer you have accepted explains why. If not, then I would suggest you read the wonderful JCIP. – Sink

Answer 1

No, getter will not cause the field to be synchronized.

when talking about reading and writing a primitive in a multi-threaded environment, we have three problems, caused by the CPU

1. Atomicity : it may require the store or load operation more than one assembly instruction, for example, writin into a 64-bit integer on a 32-bit CPU. the current thread may be put to sleep by the operating system in the middle of the instruction sequence.
2. Visibility : a thread that runs on one core may not read the latest value that other thread from other core has written. simply because the CPU says so.
3. Reordering : in order to make the program run faster, the CPU blends the order of the assembly instructions as it sees fit.

Getter doesn't solve any of these problem. even if it was, the JIT compiler may completely optimize that function away. than what?

Volatile is one of the ways to solve of the problems above. so does a lock. they ensure that one thread reads the latest value of the primitive, or make sure that a value being written is visible to other threads. they also cause the assembly instructions to run exactly as they were compiled, without any blending.

As a side note, the generated assembly may look completely different from what you have written in your code. you ask yourself "I wrote in my code to read from flag, so why wouldn't the program read from the field itself?" the compiler may do whatever it sees fit to make the assembly fast as possible. by not adding any locks or volatile specifier, you basically told the compiler that no multi-threaded access is involved and the compiler (and subsequently, the CPU) is free to assume that the object is not touched by multiple threads. it could be that this object may not be created at the first place. the JIT compiler may say "well, declare this boolean in a register and treat that as the entire object". it is very possible.

Edit: Is it true that the entire object is cached by a thread (including the private field), so that when I call the getter it will return the cached private field?

You cannot assume that. it is up to the JVM, the underlying OS and the underlying CPU. it may be cached completely, partially or not at all. to remind you, most of the CPU's out there have more than one cache line, even if the object is cached, where is it cached? in the registers or one of the cache lines?

Fineman

"Java solves the first problem" - see JLS 17.6; reading and writing of a non-volatile 64 bit value is not guaranteed to be atomic. – Sink

@BoristheSpider also, what about out of thin air guarantee? – Fineman

See this answer. The thread may see partially updated data - the point is that it isn't random data. – Sink

Answer 2

I'm wondering if a getter method for a private boolean field forces the other threads to get the latest updated value

No. It does not force other threads to get the latest value in absence of volatile keyword.

Is this an alternative for volatile field?

No. Simple getter call is not alternative to get latest value of boolean value in absence of volatile keyword.

Better solution to solve your problem : Use AtomicBoolean

A boolean value that may be updated atomically. See the java.util.concurrent.atomic package specification for description of the properties of atomic variables.

Few more useful links:

Atomic package-summary

What is the difference between atomic / volatile / synchronized?

Kigali

Answer 3

getter forces a thread to get an uncached value? Is this an alternative for volatile field?

No, getter method doesn't force anything, so you must need a volatile so that the current thread sees the latest value updated by the other threads, otherwise, you might see the stale values.

You need to know the below text from here and understand the concept of atomic access clearly.

volatile variable are always visible to other threads. It also means that when a thread reads a volatile variable, it sees not just the latest change to the volatile

Divorcement

Isn't a getter method supposed to get the real value? Or is it that the entire object is cached (including the private field), so that when I call the getter it will return the cached private field? – Eslinger

@ovidiu-miu a "getter" is in no way special. It's simply a method, like any other. It takes arguments and returns a value. When a variable is read by multiple threads, those reads may be inconsistent. Full stop. – Sink

Answer 4

If you use synchronized keyword with the two methods then yes:

public synchronized boolean getFlag() {
    return this.flag;
}

public synchronized void setFlag(boolean flag) {
    this.flag = flag;
}

Then these two methods are equivalent to using volatile on the instance variable

Ophthalmologist