Dear Java Memory Modelers:
It's been some time since Bill and Jeremy posted the New Approach, and I've
been meaning to say someting ever since first scanning the document ....
Given my background in transaction processing models, I grasp
happens-before (partial) orderings reasonably well (though I, like some
other respondents, prefer the "arrows" to go the other way, namely e1->e2
if e2 happens-after e1). But I found the document and its definitions
confusing. I think what bothered me is that there seemed to be some
not-very-explicit underlying global time ordering. Where I got this
impression was the use of words such as "before", "after", "earlier", and
"later". Now this is from memory, so I may not have it exactly right, but I
do recall that at least some happens-before edges were defined in terms of
a implicit time model.
I urge you to make that model more explicit, in order to make your model
more clear. Personally, I would prefer NOT using an underlying total
ordering -- in physically dispersed systems, under special relativity not
all events will be perceived in the same order by all observers. But SOME
events will be. I would say that IN EFFECT you should be defining the
"relativity model" for Java memory.
This need not correspond exactly to special relativity. Among other things,
messages (conveying "information" from "place" to "place") may move at
varying speeds, etc.
It would be tempting to model each memory location as a "place", and events
occurring at a particular "place" CAN be ordered by time. (It is events at
DIFFERENT places that will not always be ordered the same by all
observers.) However, I envision wanting to support the JMM in a distributed
shared memory environment, where each memory location is NOT stored in a
single place. I think we should avoid overly constraining the ordering of
operations on memory locations.
My impression is that Bill and Jeremy were trying to do more or less what I
have in mind. I _think_ the goal was define a happens-before (could be
happens-after :-) such that a memory read would always be ordered
(immediately, i.e., not transitively) after one OR MORE writes, and also
before one or more writes ("before" and "after" here meaning according to
the happens-before relation). The read would then be constrained to provide
a value equal to that written by one of the immediately preceding writes.
What I like about this model is that it might be possible to allow a
volatile read (for example) to return any of several values for a period of
time, but to require that eventually, if no further writes occur to the
memory location (for example), the "contents" of the location would
"stabilize" on a single value -- but if two writes were not ordered by
happens-before, it could be the value written by either one. Note that this
would allow the (perceived) value to "fluctuate" for a while before
becoming "stable". I can implement this semantics more easily and cheaply
than sequential consistency, for example.
It would also be possible to devise a semantics in which the value is not
required to become "stable" in the face of volatile writes unordered by
happens-before, though that semantics may be less useful. (It may be
reasonable for NON-volatile writes: serves you right if you don't use
synchronization!)
The end result is that data races on non-volatiles would be pretty useless,
since the resulting value could "fluctuate" (but only among the values
written by the most recent unordered writes), and data races on volatiles
would eventually give "stable" values, but not within any specific time
period.
Clearly lock acquisition and release add happens-before edges that serve to
"stabilize" values written.
I think this gets us our safety guarantees, can allow all the compiler
optimizations we like, and also allows efficient implementation of Java
DSM, interesting concurrent garbage collectors (like Sapphire :-), and so
on.
Is this any help in the conversation?? Eliot
==============================================================================
J. Eliot B. Moss, Associate Professor http://www.cs.umass.edu/~moss www
Department of Computer Science +1-413-545-4206 voice
140 Governor's Drive, Room 372 +1-413-545-1249 fax
University of Massachusetts moss@cs.umass.edu email
Amherst, MA 01003-9264 USA +1-413-545-3733 Priscilla Coe sec'y
==============================================================================
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:41 EDT