program order: hard to understand definition

  • Thread starter pvbemmel-at-xs4all-nl
  • Start date
P

pvbemmel-at-xs4all-nl

I find it hard to match my intuition of program order, as being
the order given by lines in the source code,
to definition of "program order" in the Java Language Specification.
The definition given by wikipedia, seems much clearer.
Both are reproduced below.

Why is the JLS definition so hard to understand?

Can anybody explain?

Paul van Bemmelen.

The Java Language Specification, Third Edition, section 17.4.3 "Programs
and Program Order" , states:
----------------------------------------------
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.
----------------------------------------------

The introduction to section 17.4 "Memory Model" , states about
"intra-thread semantics" :
----------------------------------------------
The memory model determines what values can be read at every point in
the program. The actions of each thread in isolation must behave as
governed by the semantics of that thread, with the exception that the
values seen by each read are determined by the memory model. When we
refer to this, we say that the program obeys intra-thread semantics.
Intra-thread semantics are the semantics for single threaded programs,
and allow the complete prediction of the behavior of a thread based on
the values seen by read actions within the thread.
----------------------------------------------

In www.wikipedia.org , the entry for "java memory model" states
-----------------------------------------------
For execution of a single thread, the rules are simple. The Java
Language Specification requires a Java Virtual Machine to observe
within-thread as-if-serial semantics. The runtime (which, in this case,
usually refers to the dynamic compiler, the processor and the memory
subsystem) is free to introduce any useful execution optimizations as
long as the result of the thread in isolation is guaranteed to be
exactly the same it would have been had all the statements been executed
in the order the statements occurred in the program (also called program
order).
-----------------------------------------------
 
A

Arne Vajhøj

I find it hard to match my intuition of program order, as being
the order given by lines in the source code,
to definition of "program order" in the Java Language Specification.
The definition given by wikipedia, seems much clearer.
Both are reproduced below.

Why is the JLS definition so hard to understand?

Can anybody explain?

Language specifications are written by language
specialists for language specialist.

Wikipedia is written by ordinary users for
ordinary users.

Different context => different result.

And it is not really IT specific.

Imagine two engine engineers from Ford and GM discussing
fuel injection and an ordinary car owner listening to
the discussion.

Arne
 
J

Joshua Cranmer

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.
 
E

Eric Sosman

I find it hard to match my intuition of program order, as being
the order given by lines in the source code,
to definition of "program order" in the Java Language Specification.
The definition given by wikipedia, seems much clearer.
Both are reproduced below.

Why is the JLS definition so hard to understand?

Can anybody explain?

The JLS does not have the freedom to indulge in imprecise phrases
like "as-if-serial semantics." You'll note that Wikipedia does not
even attempt to define what it means by "as-if-serial," but that the
JLS language tries to nail down precisely what it means.

Challenge: Define "sweet" without using words that appeal to the
reader's pre-existing notions of sweetness: Define it without saying
"sugar" or "honey" or "molasses" or any such, just define it from the
ground up. Then pour it on your pancakes and see how it tastes. ;-)
 
J

Joshua Cranmer

Challenge: Define "sweet" without using words that appeal to the
reader's pre-existing notions of sweetness: Define it without saying
"sugar" or "honey" or "molasses" or any such, just define it from the
ground up. Then pour it on your pancakes and see how it tastes. ;-)

A substance is "sweet" if it contains, in relatively large amounts, a
set of chemicals whose stereochemistry places certain functional groups
in specific relevant positions that allow chemical conformational
changes in specialized receptors on the human tongue, specifically those
found most predominantly in the forward portion of the tongue. Examples
of chemicals which activate these receptors include
(2R,3R,4S,5S,6R)-2-[(2S,3S,4S,5R)-3,4-dihydroxy-2,5-bis(hydroxymethyl)oxolan-2-yl]oxy-6-(hydroxymethyl)oxane-3,4,5-triol,
N-(L-α-Aspartyl)-L-phenylalanine, 1,1-Dioxo-1,2-benzothiazol-3-one, and
(2R,3S,4R,5R)-2,3,5,4,6-Pentahydroxyhexanal.

And no, do not ask me to diagram those molecules.
 
J

Joshua Cranmer

(2R,3S,4R,5R)-2,3,5,4,6-Pentahydroxyhexanal.

My bad. In my haste to respond, I neglected to remember that this is
actually not the stereochemical form detected. The aldehyde would
actually tautomerize into a cyclic hemiacetal for this. I leave the ways
in which this happens as an exercise for the reader.
 
E

Eric Sosman

Challenge: Define "sweet" without using words that appeal to the
reader's pre-existing notions of sweetness: Define it without saying
"sugar" or "honey" or "molasses" or any such, just define it from the
ground up. Then pour it on your pancakes and see how it tastes. ;-)

A substance is "sweet" if it contains, in relatively large amounts, a
set of chemicals whose stereochemistry places certain functional groups
in specific relevant positions that allow chemical conformational
changes in specialized receptors on the human tongue, specifically those
found most predominantly in the forward portion of the tongue. Examples
of chemicals which activate these receptors include
(2R,3R,4S,5S,6R)-2-[(2S,3S,4S,5R)-3,4-dihydroxy-2,5-bis(hydroxymethyl)oxolan-2-yl]oxy-6-(hydroxymethyl)oxane-3,4,5-triol,
N-(L-α-Aspartyl)-L-phenylalanine, 1,1-Dioxo-1,2-benzothiazol-3-one, and
(2R,3S,4R,5R)-2,3,5,4,6-Pentahydroxyhexanal.

You forgot the part about pouring it on your pancakes ...

"Unnngggh! Urrrrggh! Honey, can you hand me the pliers? The lid
on this jar of N-(L-α-Aspartyl)-L-phenylalanine is stuck solid."
 
T

Tom Anderson

The JLS does not have the freedom to indulge in imprecise phrases
like "as-if-serial semantics." You'll note that Wikipedia does not
even attempt to define what it means by "as-if-serial," but that the
JLS language tries to nail down precisely what it means.

Challenge: Define "sweet" without using words that appeal to the
reader's pre-existing notions of sweetness: Define it without saying
"sugar" or "honey" or "molasses" or any such, just define it from the
ground up. Then pour it on your pancakes and see how it tastes. ;-)

That's not fair. Sweet is a quale - it can't be described without
reference to subjective experience. Not even by the JLS authors.

tom
 
P

pvbemmel-at-xs4all-nl

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...


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 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.

I AM interested in interthread memory consistency semantics.
And I DO appreciate a precise definition.

I don't find the linevery precise: what is meant by "reflects" ?

Also, the line
>The actions of each thread in isolation must behave as governed by the
>semantics of that thread, with the exception that the values seen by
>each read are determined by the memory model.

is like a forward reference: in the process of defining the behaviour of
a thread, you refer to the "semantics of that thread". And even
stranger, it says that there is an exception to those semantics.
Surely, with "the semantics of that thread", something specific is
meant, but what can that be?

Paul van Bemmelen.
 
J

Joshua Cranmer

I don't find the line
very precise: what is meant by "reflects" ?

Think of it as saying that the two are isomorphic.
Also, the line


is like a forward reference: in the process of defining the behaviour of
a thread, you refer to the "semantics of that thread". And even
stranger, it says that there is an exception to those semantics.
Surely, with "the semantics of that thread", something specific is
meant, but what can that be?

You have to read the entire section carefully, but it clearly states
that, in the absence of multiple threads, the semantics of a single
thread follow the execution order for that thread, which is a specific
order given in a subsection of §15, §15.4 I believe.
 
R

Roedy Green

Why is the JLS definition so hard to understand?

the JLS is aimed at compiler writers. It is a lawyerly document about
corner cases. To learn the language you need a text book crammed full
of examples. Even a free out-of-date book will do. You can then learn
the latest stuff online.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,968
Messages
2,570,152
Members
46,697
Latest member
AugustNabo

Latest Threads

Top