[cpp-threads] RE: Initial comments on your straw man

[Nick Maclaren]

I doubt that there is any chance that WG14 will do anything useful
in this respect.  Your explanation will do as well as any for why,
though there is more to it than that.

Generally, I think that abandoning sequence points and going for
"sequenced before" makes a lot of sense.

It also fixes the following problem:

     tail = work[tail] = i;

In C, that is technically illegal, but there is a LOT of code that
does it, and only a really weird implementation would get it wrong.
Just like a[a[0]] = k;


1.9p9  I tried to get C to adopt C++'s rule, but failed.  C++ allows
a handler to count interrupts, which is very important.


1.9p11  There is a problem with this, but I can't remember the exact
construction where I got caught.  I think that it was something like:

    volatile int a[10];

    a[5] = 0;

but it wasn't that simple.  The "gotcha" was that a[5] is *('&a'+5),
or whatever it was, and the qualification got lost when one of the
intermediate lvalues was created.  Anyway, the compiler (legally)
did not treat the intermediate value as volatile, and my program
blew up in my face when I used setjmp.  The cure was to abandon
the offending construction and use one that I could force volatile
at all stages.

I don't know if C++ has the same gotcha, but I wouldn't bet that it
doesn't have.  The interactions between volatile objects and
intermediate lvalues and rvalues in expressions is a nightmare.


1.9p16  This also needs to close the exception loophole I mentioned,
by saying that all evaluations and side effects associated with the
function call are sequenced before an exception thrown by that
function call is caught outside it.  This is not a consequence of the
full expression rules.

I am afraid that you still need to close the f()+g() problem.
I really DO mean that there were AND ARE compilers that call them
in parallel, because there is a perfectly good model where your
wording does not require them to be serialised.  I don't think
that C++ allows the current compilers to do it for C++, but C90
does for macros and C99 is unclear whether it does for inline
functions.  There was a LONG argument on this one on the WG14
reflector, and no consensus was reached.

For other people, the model is where the calling function schedules
f() and g() in separate threads, and then suspends itself waiting
for them to finish, whereupon it adds the results.  Very natural,
if you are thinking parallel, and it meets the wording of C and C++,
but does not serialise the calls.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679