JavaMemoryModel: (Proposal) Semantics must satisfy Linking Monotonicity.

From: Vijay Saraswat (vijay@saraswat.org)
Date: Thu Feb 26 2004 - 14:40:11 EST


(Assume we are working with a simple language, as in the JSR document
where pointer aliasing issues do not arise, i.e. the mapping between
names in source text and locations in runtime memory is one to one.)

Define a linking L to be a mapping of reads in a source program with
writes in the source program to the same location. An execution is said
to satisfy L if the value obtained from memory at read r is the same as
the value written to memory at L(r).

Linking Monotonicity Principle: Given a program P and a linking L, if P
has an execution satisfying L, then P || Q should have an execution
satisfying L (for any program Q).

The intuition behind this principle is that the implementation should be
able to link reads to writes compositionally, that is, without having to
examine the entire program. Intuitively, it should be possible to
postpone the first step of Q till after P has finished the portion of
its execution sequence which satisfies L. So Q should not be able to
prevent the system from implementing P as if it existed in isolation
from Q (at least any arbitrarily finite prefix of P, if you are
concerned about fairness issues).

*Semantics* should not depend on having the *entire* program available,
though of course an implementation might.

Please think about this and try and make up your mind on whether you buy
this without reading the rest of this message....

Best,
Vijay
====================================

And now the rest of the message :-)

An implication of this principle is that Test Case 18 should be
forbidden, not allowed. The analysis that R3!=0 "implies" R3=42 depends
on a closed world assumption, and is invalidated if you add another
thread that "may" write to X, though in fact it never will. That is, a
possible behavior of P is ruled out by running another program Q in
parallel with it.

Where is this principle coming from? Over the last ten years there has
been a lot of research on causality in concurent programming languages
(particularly synchronous programming languages). (There is a *lot* of
research in engineering on causality, and closer to computer science, in
AI and Qualitative Reasoning.) Gerard Berry introduced certain
constructs in Esterel in the early 90s that relied on what my colleagues
and I later called "negative information", i.e .the absence of
information. We wrote a series of papers on Timed Concurrent Constraint
Programming, and then Default Timed Concurrent Constraint Programming
which analyzed this phenomena in detail (see LICS 94, POPL 95, the
journal papers etc accessible from
http://www.stratify.com/emp/staff/resteam/vgupta/ )

A program depending on negative information allows computation to
progress on the *absence* of information. Usual control constructs rely
on the presence of information, e.g. read the information currently
present in memory location x, interprete it as an integer, add it to the
bits currently present in y, write it into z etc etc. An example of a
control construct that depends on negative information is the "if c else
A" of Default CCP. It says that in the absence of information c now *and
for the duration of the computation*, execute A. The construct,
naturally enough, leads to causal loops (e.g. what if A causes c to
happen) which end up implying that there are *no* behaviors for certain
programs. (e.g. if d else d). A large part of the sophistication of
the mathematical (operational and denotational) models we developed was
devoted to understanding this phenomena, and presenting a simple
account for it in terms of the meaning of a program as a set of pairs of
fixed points.

What does this mean here? The value (42) returned by a read (the read of
R3 in Line 1 of Case 18) for the case in question depends on knowledge
that a particular write (43) has not happened *and cannot happen in the
future*. This is the default assumption that is violated when another
program is run in parallel with it.

Default assumptions are complicated to deal with, though we showed that
in fact denotational models are possible. But I am not quite sure I
believe that they belong in a production language like Java just yet.

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:58 EDT