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

[Nelson, Clark]

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

Hmm. I don't see how it's possible to lose volatility here in a way that
matters. (a) and (a+5) both have type (volatile int *). Of course those
rvalues are not themselves volatile-qualified, but the * expression is
unquestionably a volatile-qualified lvalue, so the assignment needs to
be treated as volatile.

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

Is it not? If we assume that an exception can't be caught before it is
thrown (:-), the full-expression rules would take care of all side
effects in full-expressions evaluated before the throw-expression. But
there is probably room to nail down the sequencing of any executions of
a copy-constructor when throwing an exception.

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

The net result here is that, if there is a problem remaining for C++, I
don't see it.

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

Fine, but what about my proposed wording: "The execution of the called
function is sequenced before any further operation of the calling
function."

I was waving my hands a little bit there -- I did disclaim that I had
produced polished standardese -- but the intention is certainly that
"any further operation of the calling function" includes invoking any
other function.

Clark