[cpp-threads] infinite loops

[jimmaureenrogers at att.net]

 -------------- Original message ----------------------
From: "Boehm, Hans" <hans.boehm at hp.com>

> Note that this issue really has nothing to do with optimizing infinite
> loops, which are rare.  It has to do with optimizing loops for which the
> compiler cannot prove termination.  I expect these are in the majority
> for code that I write, since they tend to include all loops traversing
> linked data structures.

Infinite loops are actually quite common in concurrent systems used
in real-time control systems. For instance, avionic control systems 
must run without any detectable termination other than system 
shut-down. 

I believe it is valuable to consider both true infinite loops and
loops for which the compiler cannot prove termination. 

Race conditions cannot be entirely prevented by language rules and
compiler analysis. The application programmer must also share 
some responsibility for avoiding race conditions. Any
unprotected access to global variables through multiple threads
presents the possibility of race conditions. The language cannot 
prevent the use unprotected global variables. Appropriate
mutual exclusion facilities must be used by the programmer.
A compiler could determine that a global is accessed without
mutual exclusion protection from more than one thread, and
issue a warning to the programmer, as long as the language
supports semantics and syntax which the compiler can 
recognize as mutual exclusion protection.

This whole area of optimization of threaded applications
is much more difficult when threading is supported through
libraries only, and not through changes in language syntax.

In Java and Ada the problems with globals are greatly 
reduced since neither language supports true globals.
Java variables must be defined in some class. Ada variables
must be defined in some package specification. In both
languages the class or package specification containing
the shared variable(s) must be explicitly referenced as
a compilation dependency. Nonetheless, both languages 
offer ample opportunities for the use of unprotected
shared variables. It is up to the programmer to avoid
access to unprotected shared variables in a concurrent
design.


--
Jim Rogers
Colorado Springs, Colorado
U.S.A.