It is now over 10 years since I was last involved in writing a memory
model (Sparc V9). In the interests of simplicity the RMO model admits
non-causal traces. The cure was deemed worse than the disease. The
only effect would be some unnecessary synchronization in somewhat
obscure and unlikely code. Is relaxing the Java memory model for the
sake of simplicity a viable option?
Paul
Sarita Adve wrote:
>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
>
>
-------------------------------
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