[cpp-threads] infinite loops

[Boehm, Hans]

I probably should have stated this more carefully:  Infinite loops
certainly occur.  However, I believe that infinite loops that perform
neither I/O operations nor reads from shared locations are quite rare.
It's only this group for which I was proposing undefined semantics.

As far as the treatment of shared variables, etc. is concerned, I'm not
really sure there are large inherent differences between C++ and other
languages, except as a consequence of type-safety and sandboxing issues.
(And in that respect I think that C++ and Ada are actually more similar
than different.) In reality shared variables in C++ will be either
private to a file, or declared in a header file that's included by all
clients.  I don't see why that's fundamentally different from the Java
or Ada situation.   Do you want to explain?

There is ongoing discussion about syntax changes to C++ to support
threading.  But I'm not sure that those have a lot of bearing on this
issue either.  It is critical that the language specification and
compiler address the presence of threads.  But I think you can get
things right whether the threading primitives themselves are expressed
as library calls, or have different syntax.  (Syntax may clearly make
things some things more convenient.) 

Hans

> -----Original Message-----
> From: jimmaureenrogers at att.net [mailto:jimmaureenrogers at att.net] 
> Sent: Sunday, July 30, 2006 11:00 PM
> To: C++ threads standardisation; C++ threads standardisation
> Cc: Boehm, Hans
> Subject: Re: [cpp-threads] infinite loops
> 
> 
>  -------------- 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.
>