[cpp-threads] infinite loops

[Bill Pugh]

Sorry to have sat this out for a while.

I must say I find it profoundly disturbing that we are considering
defining the C++ spec so that programs that exhibit no data races
in any sequentially consistent execution are allowed to exhibit
behaviors that are not sequentially consistent.

I'd also hate to think that a program that uses BigIntegers to search
for a counter example to Fermat's last theorem would be defined
as having semantics only if Fermat's last theorem is false.

I think the current efforts are bending too far backwards to accommodate
the errors in existing compilers. it has been known for years, before  
the JMM,
that there was a problem with the standard definition of control  
dependence
(although this problem wasn't widely understood).

Now, we are trying to define a semantics for C and C++ so it will be  
possible
to write reliable multithreaded software in C++ for the 64 core  
desktop machine
I'll have in 8 years. I fear greatly the result if we bend too far  
backwards to accommodate
errors in existing compilers, with no empirical data to show that  
using the broken definition
for control dependence gives substantial performance advantages.

No objections to using the correct definition in Java were raised. If  
someone could
provide data showing that by using the broken definition we could get  
a 25% performance
improvement on a major benchmark, we might want to consider using the  
broken definition
in C/C++. But otherwise, we shouldn't continue to make it harder to  
write correct
multithreaded C/C++ codes.

All the C/C++ compiler writers are going to have to expend serious  
effort to
make their compilers ready for multithreaded code. Han's work has  
shown this.
This is just one more thing that will need to be fixed. If we don't  
fix the widely used
definition of control  dependence now, it will still be broken 100  
years. Now is the
time to fix it.

Bill