Skip to content

Tag: volatile

Why is volatile keyword not needed for inter-thread visibility when one of the threads involved is the main() thread?

Consider the following program: Here the stopRequested is not declared as volatile – so ideally the thread backgroupdThread must not stop – and execute endlessly But when running this locally – the thread backgroundThread is gracefully shutting down with the message: “Stopping the thread!!”. Are all the updates by the main() thread to the shared variable stopRequested visible to the

Volatile variable explanation in Java docs

when a thread reads a volatile variable, it sees not just the latest change to the volatile, but also the side effects of the code that led up the change This is mentioned at Can someone please provide an example of this? This first gave me an impression that the thread that reads a volatile variable will synchronize with

volatile with release/acquire semantics

Since Java 5, the volatile keyword has release/acquire semantics to make side-effects visible to other threads (including assignments to non-volatile variables!). Take these two variables, for example: Note that i is a regular, non-volatile variable. Imagine thread 1 executing the following statements: At some later point in time, thread 2 executes the following statements: According to the Java memory model,