«

A. Bolmarcich wrote:
> On 2007-01-31, Knute Johnson <> wrote:
>> This is why I keep asking these questions because I get different
>> answers. Can you explain what is meant in the documentation then by:
>>
>> JLS 17.4.4 Synchronization Order
>> ...
>> A write to a volatile variable (§8.3.1.4) v synchronizes-with all
>> subsequent reads of v by any thread (where subsequent is defined
>> according to the synchronization order).
>
> Note that "subsequent is defined according to the synchronization order".
> Earlier in the section synchronization order is defined of an execution.
> Different executions may have different synchronization orders.
>
> According to the section 17.4.5 Happens-before Order: "It should be noted
> that the presence of a happens-before relationship between two actions
> does not necessarily imply that they have to take place in that order in
> an implementation. If the reordering produces results consistent with a
> legal execution, it is not illegal."
>
> If there is nothing that forces the ordering of an execution to be that
> the write action is before the read, then the read may occur before the
> write.
>
> Your previous question was: "I want to know if making the variable
> volatile will guarantee that the second thread always sees the latest
> integer created by the first thread." The answer depends on exactly
> what you mean by "latest". The second thread will always see the most
> recent write action by the first thread that has completed. However,
> unless you have another synchronization action to force what you
> consider to be the most recent write to be done before the read, the
> answer is no.

Thanks very much for your response. The two actions are independent and
I do not want to effect when they occur. I just want to ensure that if
an assignment is made to the variable that any subsequent read in the
other thread will have the latest value.

--

Knute Johnson
email s/nospam/knute/

On 2007-01-31, Knute Johnson <> wrote:
> Thanks very much for your response. The two actions are independent and
> I do not want to effect when they occur. I just want to ensure that if
> an assignment is made to the variable that any subsequent read in the
> other thread will have the latest value.

Without any other sychronization action between the threads, the only
way you know that a read was subsequent to a write is based on the value
that was read. A read is subsequent to a write that wrote the value
that was read.

The fact that the variable is volatile means that reads and writes by
a thread cannot be reordered to be before the previous synchronization
action or after the next synchronization action. According to section
"8.3.1.4 volatile Fields" of the JLS (from
http://java.sun.com/docs/books/jls/t...es.html#36930),
given the class

class Test {
static volatile int i = 0, j = 0;
static void one() { i++; j++; }
static void two() {
System.out.println("i=" + i + " j=" + j);
}
}

If method one() is repeatedly called by one thread and method two() is
repeatedly called by another thread, then according to the JLS:

Therefore, the shared value for j is never greater than that for i,
because each update to i must be reflected in the shared value for i
before the update to j occurs.

If the variables i and j were not volatile, then lines printed by method
two() may have a value of j greater than that of i.

A. Bolmarcich wrote:
> On 2007-01-31, Knute Johnson <> wrote:
>> Thanks very much for your response. The two actions are independent and
>> I do not want to effect when they occur. I just want to ensure that if
>> an assignment is made to the variable that any subsequent read in the
>> other thread will have the latest value.
>
> Without any other sychronization action between the threads, the only
> way you know that a read was subsequent to a write is based on the value
> that was read. A read is subsequent to a write that wrote the value
> that was read.
>
> The fact that the variable is volatile means that reads and writes by
> a thread cannot be reordered to be before the previous synchronization
> action or after the next synchronization action. According to section
> "8.3.1.4 volatile Fields" of the JLS (from
> http://java.sun.com/docs/books/jls/t...es.html#36930),
> given the class
>
> class Test {
> static volatile int i = 0, j = 0;
> static void one() { i++; j++; }
> static void two() {
> System.out.println("i=" + i + " j=" + j);
> }
> }
>
> If method one() is repeatedly called by one thread and method two() is
> repeatedly called by another thread, then according to the JLS:
>
> Therefore, the shared value for j is never greater than that for i,
> because each update to i must be reflected in the shared value for i
> before the update to j occurs.
>
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.

So that's a yes?

--

Knute Johnson
email s/nospam/knute/

On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
wrote:
> On 2007-01-31, Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
>
> > Thanks very much for your response. The two actions are independent and
> > I do not want to effect when they occur. I just want to ensure that if
> > an assignment is made to the variable that any subsequent read in the
> > other thread will have the latest value.
>
> Without any other sychronization action between the threads, the only
> way you know that a read was subsequent to a write is based on the value
> that was read. A read is subsequent to a write that wrote the value
> that was read.
>
> The fact that the variable is volatile means that reads and writes by
> a thread cannot be reordered to be before the previous synchronization
> action or after the next synchronization action. According to section
> "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
> given the class
>
> class Test {
> static volatile int i = 0, j = 0;
> static void one() { i++; j++; }
> static void two() {
> System.out.println("i=" + i + " j=" + j);
> }
> }
>
> If method one() is repeatedly called by one thread and method two() is
> repeatedly called by another thread, then according to the JLS:
>
> Therefore, the shared value for j is never greater than that for i,
> because each update to i must be reflected in the shared value for i
> before the update to j occurs.
>
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.
Actually, they still might.
imagine this scenario:

Thread 2: two gets called
Thread 2: value i is loaded and converted to a string for
concatication
Thread 1: one gets called
Thread 1: one gets called again
Thread 1: one gets called a third time
Thread 2: continues with j

Output is i=0 j=3

Also possible is:
Thread 1: one gets called
Thread 1: increments i
Thread 2: one gets called
Thread 2: increments i
Thread 3: two gets called
Thread 3: output i=2 j=0
Thread1: increments j
Thread2: increments j


A even worse possibility:
Thread 1: reads value of i
Thread 2: reads value of i
Thread 1: writes value of i+1 back to i
Thread 2: writes values of i+1 back to i
Thread 1: increments j
Thread 2: increments j
Thread 3: wait for thread1 and thread2
Thread 3: call two
Output i=1 j=2

On 2007-01-31, Knute Johnson <> wrote:
> A. Bolmarcich wrote:
>> On 2007-01-31, Knute Johnson <> wrote:
>>> Thanks very much for your response. The two actions are independent and
>>> I do not want to effect when they occur. I just want to ensure that if
>>> an assignment is made to the variable that any subsequent read in the
>>> other thread will have the latest value.
>>
>> Without any other sychronization action between the threads, the only
>> way you know that a read was subsequent to a write is based on the value
>> that was read. A read is subsequent to a write that wrote the value
>> that was read.
>>
>> The fact that the variable is volatile means that reads and writes by
>> a thread cannot be reordered to be before the previous synchronization
>> action or after the next synchronization action. According to section
>> "8.3.1.4 volatile Fields" of the JLS (from
>> http://java.sun.com/docs/books/jls/t...es.html#36930),
>> given the class
>>
>> class Test {
>> static volatile int i = 0, j = 0;
>> static void one() { i++; j++; }
>> static void two() {
>> System.out.println("i=" + i + " j=" + j);
>> }
>> }
>>
>> If method one() is repeatedly called by one thread and method two() is
>> repeatedly called by another thread, then according to the JLS:
>>
>> Therefore, the shared value for j is never greater than that for i,
>> because each update to i must be reflected in the shared value for i
>> before the update to j occurs.
>>
>> If the variables i and j were not volatile, then lines printed by method
>> two() may have a value of j greater than that of i.
>
> So that's a yes?

Like many questions about the interaction of multiple threads, the
question does not have a simple "yes" or "no" answer. The best that I
can respond is to repeat: a read is subsequent to a write that wrote the
value that was read. If that is what you mean by "subsequent read" in
your qestion, the answer is "yes".

On 2007-01-31, Daniel Pitts <> wrote:
> On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> wrote:
>> On 2007-01-31, Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
>>
>> > Thanks very much for your response. The two actions are independent and
>> > I do not want to effect when they occur. I just want to ensure that if
>> > an assignment is made to the variable that any subsequent read in the
>> > other thread will have the latest value.
>>
>> Without any other sychronization action between the threads, the only
>> way you know that a read was subsequent to a write is based on the value
>> that was read. A read is subsequent to a write that wrote the value
>> that was read.
>>
>> The fact that the variable is volatile means that reads and writes by
>> a thread cannot be reordered to be before the previous synchronization
>> action or after the next synchronization action. According to section
>> "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
>> given the class
>>
>> class Test {
>> static volatile int i = 0, j = 0;
>> static void one() { i++; j++; }
>> static void two() {
>> System.out.println("i=" + i + " j=" + j);
>> }
>> }
>>
>> If method one() is repeatedly called by one thread and method two() is
>> repeatedly called by another thread, then according to the JLS:
>>
>> Therefore, the shared value for j is never greater than that for i,
>> because each update to i must be reflected in the shared value for i
>> before the update to j occurs.
>>
>> If the variables i and j were not volatile, then lines printed by method
>> two() may have a value of j greater than that of i.
> Actually, they still might.
> imagine this scenario:
>
> Thread 2: two gets called
> Thread 2: value i is loaded and converted to a string for
> concatication
> Thread 1: one gets called
> Thread 1: one gets called again
> Thread 1: one gets called a third time
> Thread 2: continues with j
>
> Output is i=0 j=3

Which is a case of the value of j being greater than that of i that I wrote
may occur.

> Also possible is:
> Thread 1: one gets called
> Thread 1: increments i
> Thread 2: one gets called
> Thread 2: increments i
> Thread 3: two gets called
> Thread 3: output i=2 j=0
> Thread1: increments j
> Thread2: increments j

In the extract of the JLS section, there are only two threads: one invokes
one() and the other invokes two().

> A even worse possibility:
> Thread 1: reads value of i
> Thread 2: reads value of i
> Thread 1: writes value of i+1 back to i
> Thread 2: writes values of i+1 back to i
> Thread 1: increments j
> Thread 2: increments j
> Thread 3: wait for thread1 and thread2
> Thread 3: call two
> Output i=1 j=2

In the extract of the JLS section, there are only two threads: one invokes
one() and the other invokes two().

On Jan 31, 4:24 pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
wrote:
> On 2007-01-31, Daniel Pitts <googlegrou...@coloraura.com> wrote:
> > On Jan 31, 11:40 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> > wrote:
[snip]
> >> The fact that the variable is volatile means that reads and writes by
> >> a thread cannot be reordered to be before the previous synchronization
> >> action or after the next synchronization action. According to section
> >> "8.3.1.4 volatile Fields" of the JLS (fromhttp://java.sun.com/docs/books/jls/third_edition/html/classes.html#36930),
> >> given the class
>
> >> class Test {
> >> static volatile int i = 0, j = 0;
> >> static void one() { i++; j++; }
> >> static void two() {
> >> System.out.println("i=" + i + " j=" + j);
> >> }
> >> }
>
> >> If method one() is repeatedly called by one thread and method two() is
> >> repeatedly called by another thread, then according to the JLS:
>
> >> Therefore, the shared value for j is never greater than that for i,
> >> because each update to i must be reflected in the shared value for i
> >> before the update to j occurs.
>
> >> If the variables i and j were not volatile, then lines printed by method
> >> two() may have a value of j greater than that of i.
> > Actually, they still might.
> > imagine this scenario:
>
> > Thread 2: two gets called
> > Thread 2: value i is loaded and converted to a string for
> > concatication
> > Thread 1: one gets called
> > Thread 1: one gets called again
> > Thread 1: one gets called a third time
> > Thread 2: continues with j
>
> > Output is i=0 j=3
>
> Which is a case of the value of j being greater than that of i that I wrote
> may occur.
You wrote:
> If the variables i and j were not volatile, then lines printed by method
> two() may have a value of j greater than that of i.

My example is allowing them to be volatile.
Actually, my example is valid for both volatile and non-volatile
variables.

With two threads repeatedly calling their respective methods, you can
get a situation with i > j or j > i, regardless of the volatility of
the variables.

Therefore, your post doesn't explain volatile at all.

A. Bolmarcich wrote:
> On 2007-01-31, Knute Johnson <> wrote:
>> A. Bolmarcich wrote:
>>> On 2007-01-31, Knute Johnson <> wrote:
>>>> Thanks very much for your response. The two actions are independent and
>>>> I do not want to effect when they occur. I just want to ensure that if
>>>> an assignment is made to the variable that any subsequent read in the
>>>> other thread will have the latest value.
>>> Without any other sychronization action between the threads, the only
>>> way you know that a read was subsequent to a write is based on the value
>>> that was read. A read is subsequent to a write that wrote the value
>>> that was read.
>>>
>>> The fact that the variable is volatile means that reads and writes by
>>> a thread cannot be reordered to be before the previous synchronization
>>> action or after the next synchronization action. According to section
>>> "8.3.1.4 volatile Fields" of the JLS (from
>>> http://java.sun.com/docs/books/jls/t...es.html#36930),
>>> given the class
>>>
>>> class Test {
>>> static volatile int i = 0, j = 0;
>>> static void one() { i++; j++; }
>>> static void two() {
>>> System.out.println("i=" + i + " j=" + j);
>>> }
>>> }
>>>
>>> If method one() is repeatedly called by one thread and method two() is
>>> repeatedly called by another thread, then according to the JLS:
>>>
>>> Therefore, the shared value for j is never greater than that for i,
>>> because each update to i must be reflected in the shared value for i
>>> before the update to j occurs.
>>>
>>> If the variables i and j were not volatile, then lines printed by method
>>> two() may have a value of j greater than that of i.
>> So that's a yes?
>
> Like many questions about the interaction of multiple threads, the
> question does not have a simple "yes" or "no" answer. The best that I
> can respond is to repeat: a read is subsequent to a write that wrote the
> value that was read. If that is what you mean by "subsequent read" in
> your qestion, the answer is "yes".

I have no idea what that means. By subsequent I mean the usual meaning
that the subsequent action occurs later in time than the precedent
action. So in the case I am asking about, the first thread writes to
the variable and then some time later the second thread reads the variable.

Does volatile guarantee that the second thread will see the value
written by the first thread?

Does synchronizing guarantee that the second thread will see the value
written by the first thread?

--

Knute Johnson
email s/nospam/knute/

On 2007-02-01, Knute Johnson <> wrote:
> A. Bolmarcich wrote:
>> Like many questions about the interaction of multiple threads, the
>> question does not have a simple "yes" or "no" answer. The best that I
>> can respond is to repeat: a read is subsequent to a write that wrote the
>> value that was read. If that is what you mean by "subsequent read" in
>> your qestion, the answer is "yes".
>
> I have no idea what that means. By subsequent I mean the usual meaning
> that the subsequent action occurs later in time than the precedent
> action. So in the case I am asking about, the first thread writes to
> the variable and then some time later the second thread reads the variable.
>
> Does volatile guarantee that the second thread will see the value
> written by the first thread?
>
> Does synchronizing guarantee that the second thread will see the value
> written by the first thread?

When "the first thread writes to the variable" a processor requests that
a value be written to a memory address. On some computers the request
goes into a queue and the effect of the memory write is visible to other
threads sometime later. While the memory write is being done, the first
thread continues executing.

On this type of computer architecture, whether a memory read is subsequent
to a memory write depends on the whether the read gets the value written
by the memory write. It does not depend on the global order in which
threads execute instructions.

The answer to your question: "Does volatile guarantee that the second
thread will see the value written by the first thread?", is yes, as long
as you take "some time later" being in terms of what is visible in memory
and not in terms of the global order in which the threads execute the
instruction.

The answer to your question: "Does synchronizing guarantee that the
second thread will see the value written by the first thread?" is yes,
with "some time later" being in terms of the second thread entering its
synchronized block after the first thread exited its synchronized block.

On 2007-02-01, Daniel Pitts <> wrote:
> On Jan 31, 4:24 pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> wrote:
>> On 2007-01-31, Daniel Pitts <googlegrou...@coloraura.com> wrote:
[snip]
>> > imagine this scenario:
>>
>> > Thread 2: two gets called
>> > Thread 2: value i is loaded and converted to a string for
>> > concatication
>> > Thread 1: one gets called
>> > Thread 1: one gets called again
>> > Thread 1: one gets called a third time
>> > Thread 2: continues with j
>>
>> > Output is i=0 j=3
>>
>> Which is a case of the value of j being greater than that of i that I wrote
>> may occur.
> You wrote:
>> If the variables i and j were not volatile, then lines printed by method
>> two() may have a value of j greater than that of i.
>
> My example is allowing them to be volatile.
> Actually, my example is valid for both volatile and non-volatile
> variables.
>
> With two threads repeatedly calling their respective methods, you can
> get a situation with i > j or j > i, regardless of the volatility of
> the variables.

Sorry, I did not read your scenario carefully enough. Yes, when
i and j are volatile, if two() reads the value of i and one() is invoked
again before two() reads the value of j, then two() may print j value
that is greater than the i value.