pre-LilleHammer mailing deadline

[Hans Boehm]

I've attached a final diff of my changes before submission.
These mostly reflect Andrei's changes.

I suggested to Ben that he be added as an author.

Thanks, everyone.

Hans

On Sun, 6 Mar 2005, Andrei Alexandrescu wrote:

> Hello gang,
>
>
> Great work! I am sorry I couldn't add to it this time around. Here are a
> few comments:
>
> * Page 2: "... write an ordinary shared memory location..."
>
> What is the meaning of "ordinary" here? Primitive? A more precise term
> would be useful. If the term adds no precision, we could simply remove
> "ordinary".
>
> * Page 2, footnote: spurious comma after "shared variables".
>
> * Page 2, second bullet: the leading "that" should be removed.
>
> * Page 3: "In Java, this transformation could also result in..."
>
> I think it's clearer to say: "In Java, this transformation could for
> example result in..." because this paragraph comes as an explanation of
> the unsafe operation described in the previous paragraph. Right?
>
> Then, "for example" occurs later in the same sentence which kinda steals
> my thunder. So let me propose a rewrite of the whole paragraph:
>
> "To illustrate, this transformation could result in an unchecked
> out-of-bounds array access, and hence violate type-safety if, for
> example, the pointer to a shared array is reloaded between the subscript
> check and array access."
>
> * Page 3: "some of which we are not confident can be applied C++"
>
> Forgot a "to": "some of which we are not confident can be applied to C++"
>
> * Page 3: "other threads reading that pointer"
>
> Must be plural: "other threads reading such pointers"
>
> * Page 3: "virtual or reflective methods"
>
> I confess I don't know what "reflective" means in the context above.
> Besides, the standard folks are picky about terminology, and "method"
> is, oddly enough, frowned upon. "Member function" is the sanctified
> term, sigh.
>
> * Page 4: There are a lot of "this" and "it" in 3.1, which makes the
> subsection hard to follow. At least let's change "Java disallows it." to
> "Java disallows implicit writes to any fields." I'm not even sure I
> understood things correctly enough so the rewrite is what was meant.
>
>
> Again, great work. Hopefully we'll get someone to present it at Lillehammer.
>
>
> Andrei
>
> Boehm, Hans wrote:
> > Here's the version I plan to send in later today, together with
> > a diff from the version with your patches incorporated.
> >
> > Hans
> >
> >
> >>-----Original Message-----
> >>From: Bill Pugh [mailto:pugh at cs.umd.edu]
> >>Sent: Sunday, March 06, 2005 4:24 PM
> >>To: Ben Hutchings; asharji at plg.uwaterloo.ca; Kevlin Henney;
> >>Boehm, Hans; jimmaureenrogers at att.net; Doug Lea; Maged
> >>Michael; Richard Bilson; Andrei Alexandrescu; Bill Pugh
> >>Subject: Re: pre-LilleHammer mailing deadline
> >>
> >>
> >>I made a few more tweaks after incorporating Ben's changes.
> >>
> >>The main thing I changed was that the document had said that
> >>data races can introduce non-determinism. Actually, threads introduce
> >>non-determinism,
> >>and plenty of correctly synchronized multithreaded programs are
> >>nondeterministic.
> >>
> >>So I changed the wording to spell out why data races are bad:
> >>Constructing a program that exhibits data races and is
> >>guaranteed to work correctly in spite of reorderings allowed by
> >>the
> >>memory system and by the compiler is very difficult, and
> >>data races are usually an indication
> >>of a programming error.
> >>
> >>	Bill
> >>
> >>
>
-------------- next part --------------
--- issues.tex.sent_for_approval	2005-03-06 21:07:40.419662915 -0800
+++ issues.tex	2005-03-06 21:46:29.502509941 -0800
@@ -62,7 +62,7 @@
 
 \addvspace{5pt}
 
-\hfill Doug Lea \hfill Bill Pugh \hspace*\fill}
+\hfill Ben Hutchings \hfill Doug Lea \hfill Bill Pugh \hspace*\fill}
 
 \end{center}
 
@@ -112,14 +112,14 @@
 \section{Do we define the semantics of Data Races?}
 
 A {\it data race} arises when one thread in a program can potentially
-write an ordinary shared memory location while another concurrently
+write a shared memory location while another concurrently
 accesses it.  
 Constructing a program that exhibits data races
 and is guaranteed to work correctly in spite of reorderings allowed by the 
 memory system and by the compiler is very difficult, and
 data races are usually an indication
 of a programming error.\footnote{In a few cases, concurrent
-accesses to shared variables, without locking can lead to much faster
+accesses to shared variables without locking can lead to much faster
 programs.  We plan to provide alternate mechanisms intended exclusively
 for such concurrent accesses in a way that is recognizable by the
 implementation.  They are excluded from our definition
@@ -135,7 +135,7 @@
 \begin{itemize}
 \item if a thread reads a memory location,
 no other thread can be modifying that location, 
-\item that if a thread
+\item if a thread
 writes a memory location, no other thread can be reading that location, and
 \item if a thread constructs an object, the object doesn't have to be
 	made ready for access by other threads until immediately
@@ -208,14 +208,14 @@
 caching statics).  The need to provide a full semantics for data races
 in all such cases in the Java specification introduces some of the
 more challenging technical issues in \cite{popl05}, some of which we
-are not confident can be applied \Cpp, but which can be avoided if we
+are not confident can be applied to \Cpp, but which can be avoided if we
 leave their semantics undefined.
 
 Some other implications of not defining the semantics for data races:
 \begin{itemize}
 \item Compilers would be allowed to perform tricks such
 	as XORing pointer values, which could cause
-	other threads reading that pointer to see
+	other threads reading such pointers to see
 	illegal values.
 \item Compilers could perform writes non-atomically (e.g., writing
 	a pointer as a sequence of two 16-bit writes), which 
@@ -227,7 +227,7 @@
 \item If a thread constructs an object and stores a reference
 	to that object into shared memory without synchronization,
 	then other threads that read the stored referance
-	and invoke virtual or reflective methods
+	and invoke virtual member functions
 	on that object are allowed to result in a segmentation fault
 	or other erroneous behavior.
 \end{itemize}
@@ -285,7 +285,8 @@
 support this optimization and reliable concurrent programming.  Further,
 we believe that not all high performance C++ compilers currently
 perform this transformation, so the cost of disallowing it is not huge.
-Java disallows it.
+Java disallows all implicit writes, including those introduced by
+speculative register promotion.
 
 \subsection{The meaning of ``volatile''}