pre-LilleHammer mailing deadline

[Hans Boehm]

Thanks.

I attempted to incorporate everything except the page 3 changes.

I didn't really view that as an example; it's an extension of the
preceding discussion.  In addition to unexpected effects on security
sensitive user code, it can also break type-safety for the language
itself.

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
> >>
> >>
>