Re: program order: hard to understand definition
On 11/29/2010 03:34 PM, pvbemmel-at-xs4all-nl wrote:
Why is the JLS definition so hard to understand?
Specifications, by their nature, have to be a lot more precise than
general overviews. I would note that I don't find it hard to understand,
then again, I use language specifications as my refresher on basic
syntax questions, so...
Among all the inter-thread actions performed by each thread t, the
program order of t is a total order that reflects the order in which
these actions would be performed according to the intra-thread semantics
of t.
Basically, this means that the program order is a valid ordering that
obeys all of the law of ?17--in other words, this is the ordering that
is actually done by the program at runtime.
I would also like to take the time to point out that the memory model
only stipulates a partial ordering that must be performed, so there is
some scope for program orders to be different.
The introduction to section 17.4 "Memory Model" , states about
"intra-thread semantics" :
The memory model is perhaps the most complicated part of the JLS, even
more so than, say, generics type inference during method invocation
(which is imposing, to say the least). You won't get much out of it if
you just read snippets of text; you have to carefully read it in its
entirety to digest it.
The memory model is pretty much about one thing:
"The memory model determines what values can be read at every point in
the program." (?17.4, ?3)
If you're not interested in interthread memory consistency semantics,
this section of the JLS is completely useless for you. What you would
rather want is execution order, defined in ?15.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth