Suhaas Mohandos wrote:In multithreading when exactly the local cache is updated and when main memory will be updated if not using volatile.
You are right.Suhaas Mohandos wrote:...if a variable is declared as volatile then both read and write of that variable happens from main memory
I am not sure about this.Suhaas Mohandos wrote:and the cache is not updated?
Suhaas Mohandos wrote:By definition of volatile:
By making a variable volatile using the volatile keyword in Java, application programmer ensures that its value should always be read from main memory and thread should not use cached value of that variable from their own stack.
Stephan van Hulst wrote:There is no mention of caches however.
Suhaas Mohandos wrote:Ok. Can I assume that since the JLS does not mention anything regarding cache in the definition of volatile, cache is not used for a volatile variable?
SourceJVMS Java SE 8 4.5. Fields wrote:
Each field is described by a field_info structure.
The structure has the following format:
field_info {
u2 access_flags;
u2 name_index;
u2 descriptor_index;
u2 attributes_count;
attribute_info attributes[attributes_count];
}
In access_flags:
Flag Name Value Interpretation ACC_VOLATILE 0x0040 Declared volatile; cannot be cached.
JavaTM Performance by Charlie Hunt and Binu John Page Ch 6 No 234 wrote: a volatile field’s value must be kept in sync across all application threads and CPU caches. For instance, when a volatile field’s value is changed by one thread, whose field might be sitting in a CPU cache, any other thread that might have a copy of that volatile field in its CPU cache, a different CPU cache than the other thread that performed the change, must have its CPU cache updated before its thread reads that volatile field found in its local CPU cache, or it must be instructed to retrieve the updated volatile field’s value from memory. To ensure CPU caches are updated, that is, kept in sync, in the presence of volatile fields, a CPU instruction, a memory barrier, often called a membar or fence, is emitted to update CPU caches with a change in a volatile field’s value.
Beginning Java 8 Language Features by Kishori Sharan Ch 6 Threads Java Memory Model Page no 186 wrote:A write to a volatile variable is always written to the main memory. A read on a volatile variable is always read from the main memory. That is, a volatile variable is never cached in the working memory of a thread. In effect, any write to a volatile variable is flushed to the main memory, immediately making the new value visible to other threads.
Java in a Nutshell 6th Edition Ch. 3 Page no 102 wrote:The volatile modifier says that the value of a field must always be read from and flushed to main memory, and that it may not be cached by a thread (in a register or CPU cache).
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |