paper status

[Andrei Alexandrescu]

Thanks Kevlin for the effort!

I've had a long phone conversation with Doug, and he promised he'll 
make a pass through everything tomorrow morning. I wanted to echo to 
this list some general points that were aired and some questions that 
were raised.

But first, allow me to quote a good friend and C++ guru (David B. 
Held) to whom I've emailed the current draft (if we could call it so 
:o)). I liked his message so much and agree with it so much, I decided 
to quote it in full, at the cost of your yawns.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
I see what you mean by "diving in".  The problem is, some of the 
committee members will know exactly what you're talking about, and 
most won't.  I can tell which parts Hans wrote, because he pulled them 
almost verbatim from a newsgroup post. ;)   That's fine, but Hans is
already well-versed in multi-threading issues, so he's not really 
targeting the right audience. His audience is people who are already 
somewhat familiar with threading.  I think what you need is more of a 
threading tutorial for the committee.  I suggest that you try to 
collect a set of canonical examples of standard threading practices 
and why C++ is underspecified to generate correct code for those 
examples.  Along the way, you have to explain what a memory barrier 
is, what it means for threads to be lock-free, wait-free, guaranteed 
progress, etc.

Only then is it appropriate to go into the details and nuances of 
threading in C++.  It probably wouldn't be a bad idea to mention the 
issues that Java, C, and C# faced when dealing with threads.  The fact 
that so many people think a library solution is possible means that 
you probably want to have a section addressing just that question. 
Like perhaps you could have a FAQ that at least answers the most 
common misconceptions about how to add threading to C++.  It should at 
least have these entries:

    Why can't we just add a threading library?
    Why isn't volatile good enough?
    Why can't we use pthreads?
    Why do we need to support lockless algorithms?

Issues about cancellation and whether it should be an exception or a 
return value are totally inappropriate for this proposal, IMO.  Right 
now, you are targeting complete noobs (or at least I think that is the 
assumption you should go on).

As a threading noob, I look at the paper, and I go: "Uhh...what?"  I 
mean, I've been following enough of the MT discussions that I know 
some of the issues.  But the problems are not properly motivated.  We 
know that we *want* MT support.  But many of us don't even know what 
an MT program looks like, and how it differs from an ST program.  So 
start there, and leave the details like Hans' portion for later.

I suggest you start from the very beginning, and assume that the 
committee in fact, knows absolutely nothing about threading.  Insert a 
basic tutorial which explains the fundamental problems, including the 
dining philosopher problem if you must.  The other contributors might 
not like that the proposal is worded for kiddies, but as you said 
before, there is a large divide between the MT and the non-MT camp, 
and you must bridge that divide to reach the committee.  Therefore, 
start out with kid gloves, and end with the deeper stuff.

Maybe you don't have time to write all that, and you probably don't. 
But I strongly suggest you follow your instincts and try to start out 
with a high-level statement of the problem with a very gentle 
introduction to threading first.  If the MT experts don't like it,
tell 'em "tough titty little kitty".  So at some point, have a section 
on an introduction to threading.  Give some examples of things people 
want to do with multiple threads, and why there is a problem with 
concurrent access.  Starting with the fundamentals might seem 
condescending, but you can use it effectively if you can pick some 
examples that can be reused throughout the document for different 
problems.  Anyway, you should always start out with the fundamentals 
anyway.  You don't know what you're talking about unless you can 
explain the fundamentals to a 5 year old, I always say.

So you give a simple example of two threads trying to access a shared 
resource.  You show hypothetical code that accomplishes it.  Then you 
explain what happens and what goes wrong.  Then you add 
mutexes/whatever.  You explain how this solves the problem. Maybe you 
show parallel examples in C and Java.  You explain that in C and Java, 
you are done and the program is correct.  Then you begin to explain 
why you are not done in C++.

Then you go into the issues like word tearing, memory reordering, etc. 
  Then you expand the example to something that will be obviously slow 
with a lock-based implementation. Then you say that there is an 
alternative that offers equal or better performance, and introduce the 
notion of lock-free algorithms.  Then you explain how to get that.

The current problem is that solutions and issues are being dumped on 
the reader by assuming the reader already has some idea of the issues 
involved.  But I think adding just a little more motivation at the 
beginning will help the entire paper tremendously.  At this point,
I think it's worth keeping in mind that you really cannot 
underestimate the MT experience of your audience.  So start out from 
the very beginning, and work as quickly as you can to the current 
point.  There's minor spelling errors, but I'll give it a final read 
when you are done.

Other than that, the text you have so far is great.  It just needs 
more context. ;) 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I believe these are great points. Also, Doug and I brought up the 
following issues:

* JSR 133 and 166 took years to develop, and the effort put in the 
formalisms therein are definitely worth reusing, together perhaps with 
language and library design elements.

* In wake of Kevlin's email, should the memory model and the library 
artifacts be two different proposals, or one proposal? I was hoping we 
will embark to both efforts in the long run.

* The intended audience for the document, at least at this stage, is 
quite different from what the current document shoots at. I won't 
emphasize this because Dave did.

* The document is the FIRST of MANY iteration of a proposal. It does 
NOT constitute anything close to a serious proposal (or even a 
half-assed one at that :o)).

* The document should make it clear that *we*, i.e., the authors of 
this first iteration, want to pursue the proposal. At a point Doug 
thought we might only want to send them a bullet list with "here are 
the problems that you guys need to work on". That won't work this 
millenium. Just wanted to clarify this for everyone.

So, by tomorrow morning Doug will make a pass through the doc. Doug, I 
hope the above helps as context when you start writing.

Thank you all for the effort. "The longest road starts with one step" 
the proverb says (which came before cars were invented).


Andrei