Re: Volatile happens before question
On 1/18/2012 12:08 AM, Peter Duniho wrote:
On Tue, 17 Jan 2012 23:47:38 -0800, Peter Duniho wrote:
[...]
If we have two actions x and y, we write hb(x, y) to indicate
that x happens-before y.
* If an action x synchronizes-with a following action y, then
we also have hb(x, y).
* If hb(x, y) and hb(y, z), then hb(x, z).
Tells us that any program statement _before_ "a = true" must
"happen-before" any program statement _after_ "if (!a)". Notably it, this
part at least, does not tell us anything about statements that come after
"a = true" in thread #1, nor statements that come before "if (!a)" in
thread #2.
Sorry, I seem to be making a habit of leaving out important clarification
lately. To wit: in the above, I am assuming that the statement "a = true"
actually does execute before the statement "if (!a)". Obviously, that
doesn't have to happen...thread #2 could complete before thread #1 ever
executes, or any variation on that theme. But the scenario the
specification addresses is when that does happen.
If program statement "if (!a)" occurs before "a = true", then the
specification doesn't tell us anything specific about the other statements
around those statements. Thus my interpretation that allows "bStore" to
wind up with the value of 1 even if the statement "if (!a)" observes "a" as
having the value of "false" instead of "true".
Pete
Pete:
I woke up in the middle of the night thinking about this again :-).
I made some assumptions that I'm not sure you did and that was that a
and b were safely published in thread 1 before the ... and that
execution of both threads started at that point (probably not a good
assumption but that was it). If that were not the case then b is up for
grabs until a is read in thread 2.
The other question, can b = 1 be reordered before the a = true as seen
by thread 2, I'm not really sure. I am sure that once a is read in
thread 2 b must again be 0 whether it was reordered or not. That is the
one guarantee of volatile that the memory model will be up to date for
all writes to all variables written before the write to the volatile is
subsequently read in the other thread.
So I think that my original answer to the OP is not correct. I'm not
sure how to answer the reordering question. As best I can read the JLS
there is no special case for thread with volatile assignments other than
a read following a write.
I did find a good quote for the day however, "Don't rely on clever
reasoning about why you don't need to synchronize", Brian Goetz.
--
Knute Johnson