[cpp-threads] infinite loops

[jimmaureenrogers at att.net]

I agree that most infinite loops involve I/O or memory operations. Some forms of I/O are rather specialized, such as reading sensors, or collecting a number of corresponding sensor readings and passing them through a Kalman filter.

I am unclear about the similarities you see between C++ and Ada regarding shared variables. Ada packages provide encapsulation somewhat similar to C++ namespaces. It is my understanding that variables defined within a namespace are only available to sections of C++ given visibility to that namespace. In that sense C++ and Ada have some similarities. Variables defined within a namespace are different than those defined in some header file, with no namespace encapsulation. Variables defined in a header file are visible to all parts of a C++ program which includes that header file.

All Java entities must be defined within some class. There are no free-floating variables in Java outside a class. In Java a static class is available to all sections of the code that name the class, without the need to create an instance. This produces an effect very similar to the visibility provided by C++ globals.

Ada does not provide for free-floating variables outside a package, task, or subprogram. The Ada standard does not provide a pre-processor. Variables defined in a package specification are visible only to the compilation units with a context clause identifying the package containing the variables. There is no implicit visibility to the entire program. Control of visibility in Ada is much more strict than in Java, and much more strict than C++ globals.

Part of the differences in Ada come from its somewhat unique definitions of visibility and scope. Entities in Ada can be either visible or not, visible entities can be either in scope or not. Scope and visibility are quite different concepts in Ada.

All that said, as I mentioned before, one can still make a mess of concurrent shared variables in Ada with a little effort.

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

 -------------- Original message ----------------------
From: "Boehm, Hans" <hans.boehm at hp.com>
> 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.
> >