I was waiting to finish working a few more details out before responding to
Bill's message from last Friday. But now that Eliot brings up points that
really reverberate with me, let me add my view of the situation.
First, I think Bill and Jeremy have done a tremendous job (and I have
learned a lot through our discussions). But throughout this effort, my main
complaint has been that their formalisms and models lack intuition for why
they are what they are. Hence, it has been difficult to assess whether their
model really does what it is meant to do (since I don't know what it is
meant to do). Unfortunately, I felt the same with this version.
However, in discussions with them, I believe I now understand their
intuition, and also believe a large part of it maps quite closely to my
approach. The end semantics are not identical, but close, with hope of
convergence. This makes at least me feel better because I feel my approach
is more intuitive (that's a biased opinion clearly). But all this is not yet
confirmed since I still need to finish the full mapping to convince myself.
Another problem with B/J's model is that neither causality nor consistency
are really necessary. So even when everything else works out, this is still
an issue, albeit something we can live with if there isn't an alternative.
The situation with my model is that Bill has pointed out a valid problem
with it, but it is not the one of backward slices he mentioned on Friday. I
am working on resolving that problem.
So, the upshot of all of this is that:
(1) Until I or someone else (other than Bill/Jeremy) can honestly say they
understand B/J's model, I believe we have a problem.
(2) So until then, I will continue to consider my approach a serious
candidate - to formalize what I guage to be B/J's intuition in a more
intuitive fashion and/or to present an alternative (but close) semantics to
B/J (again, in what I perceive to be a more intuitive way).
(3) Even if B/J's model is satisfactorily formalized, if I can resolve the
aforementioned problem with my model, it will have the advantage over B/J's
model of not requiring causality.
I will wrap this up from my side one way or another by the weekend.
Sarita
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Eliot Moss
> Sent: Thursday, July 24, 2003 8:59 PM
> To: Bill Pugh
> Cc: javamemorymodel@cs.umd.edu
> Subject: JavaMemoryModel: Updated JMM schedule and status report
>
>
> Bill (et al.) -- I read through JMMA and JMMB and frankly
> find them both
> pretty opaque. I don't really develop any intuition at all from them.
>
> Here is a wonderment: In the database community, within which
> I used to be
> active lo so many years ago, we have notions such as serializability
> (equivalence of a possibly interleaved execution of a set of
> transactions
> to a serial execution of the transactions in some order). Is
> there any hope
> of a similar definition and understanding for Java? For example, all
> (sets of) actions protected by the same mutex must be
> serialized, just as
> in standard database transaction models.
>
> Also, within a thread (and I guess across threads when data propagates
> through shared heap variables), I comprehend ideas like slices and
> dependences just fine.
>
> The model as presented appears to me to put "too many" edges into the
> happens-before ordering, and then to justify allowing some of them to
> "really happen" (causality) in a different order. It feels
> more intuitive
> to me to define a happens-before with fewer edges, but that is always
> causal. I suspect there's some deep reason why it can't be
> done this way,
> or perhaps it would have been. (Does it have to do with the range of
> compiler optimizations, perhaps?) What I am looking for would
> say which
> shared heap writes depend (via intermediate computation private to a
> thread) on which shared heap reads, and build up an ordering that
> way.
>
> Within a thread, presumably only dependences, mutex accesses,
> and volatile
> accesses inherently order actions on different variables;
> program order
> determines the order of actions on the same variable.
>
> Well, I could be entirely missing the point (but I remain
> concerned about
> the eventual model being understandable and useable, by all
> three of users,
> JVM builders, and hardware architects).
>
> Best wishes -- Eliot
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:46 EDT