pre-LilleHammer mailing deadline

[Andrei Alexandrescu]

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