JavaMemoryModel: RE: feedback: SC- Memory Model for Java

From: Sarita Adve (sadve@cs.uiuc.edu)
Date: Wed Nov 19 2003 - 11:09:45 EST


Joe,

Thanks for your feedback.

> -----Original Message-----
> From: Joseph Bowbeer [mailto:jozart@csi.com]
> Sent: Tuesday, November 18, 2003 1:07 AM
> To: sadve@cs.uiuc.edu
> Subject: feedback: SC- Memory Model for Java
>
>
> Sarita,
>
> Here's some feedback on
> http://rsim.cs.uiuc.edu/~sadve/jmm/jmm.full.03-11-17.1.pdf
>
> I like the structure as well as the tone and style of
> presentation. This is
> very important. I was never lost for very long, and when I
> was lost, the
> extent of the lossage was clearly bounded (-: The goal was
> usually in
> sight and generally seemed worthwhile.
>

It's good to hear that. I'll keep working at it to bound your lossage
further!

> I was a little concerned when you introduced non-atomic
> writes. I thought
> the motivation for this was a little weak and I was concerned
> that I would
> have to throw-out the intuitive understanding that I had
> built-up in the
> earlier sections. Foreshadowing may be in order!

Ok, this is very useful to know since I debated a lot on how to best present
the non-atomicity issue. On this list, for a long time, we have focused
almost exclusively on examples that result from program order
discontinuities. So I was concerned that there may not be as much of a
comfort level with examples that showed problems with write atomicity. I
think I will give a few more examples, so people can appreciate and get used
to the problem - I suspect some of these examples are going to surprise some
people. (These issues also occur in the Manson/Pugh model.)

>
> Unless I can understand the real-world importance of
> excluding cases 5 and
> 10, I would be very tempted to prefer SC- for its simplicity alone..
>
> Here are some detailed comments:
>
> 1.2 Informal requirements
>
> * The term "justify" is used several times in this section
> without any
> indication what it means or why it is needed. (Who does the
> justifying, and
> for what purpose?)
>
> * The definition of data race "causality" reads more like a
> definition of
> non-circularity. (Are definitions of causality always so indirect?
> Defining causality by stating what can't cause something
> seems inadequate.)
> When I read on page 2 about a "violation of causality that
> property 2.2
> seeks to avoid", I knew I was getting into some deep stuff!

I personally don't like the term causality in this context. I used it
because the Manson/Pugh model continues to use that term and Bill and Jeremy
have often used it to distinguish between the M/P model and SC-. My goal was
only to show that SC- is about as causal as M/P. But according to me,
neither M/P nor SC- are causal in the strongest sense of the word and I
would much rather give up usage of this term altogether for both models.

>
> 2.1 Some preliminary definitions
>
> * Near the presentation of the "correct uniprocessor"
> property may be a
> good place to hint at the non-atomic writes that are yet to come...

Hmm. Interesting suggestion. My first response is to say it may be too early
here and hard to motivate, but let me think about this some more.

>
> 2.2 Definition of SC
>
> * I have problems with the term "atomic writes". I think of
> "atomic" as
> meaning several operations are performed as one. Elsewhere
> in JLS this
> means no tearing, e.g., because all four bytes of an int are written
> atomically. I would prefer that another term be used instead
> of "write
> atomicity". "singularity"? "uniqueness"? (Some flavor or
> "coherence"?)
> If you continue to use "atomic" then you should explain the
> distinction.

This is a good point. My use of atomicity also refers to "several operations
performed as one." In a real system, a write is indeed several
"sub-operations" and the term write atomicity has been used in this context
in a lot of the memory model literature. I use it in the same way. Your
point is well taken though that we should relate it better to the next level
of atomicity, namely word tearing etc., and I will do that.
 
>
> 4. Considering Non-Atomic Writes
>
> * In the paragraph on conflict order, (c) is listed twice.

Thanks.

>
> * I suggest you append "in conflict order" to the end of the next
> paragraph.
>
> "... and/or R is ordered before W' [in conflict order]."
>
> Note: There are a few glitches that I'm not bothering to
> mention, but I
> wanted to mention the preceding one because I wasn't sure if
> I understood
> what you meant.
>

You understood right and I will add the fix.

Thanks again,

Sarita

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



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