[cpp-threads] C++ committee meeting in Mont Tremblant

[Peter A. Buhr]

   From: Andrei Alexandrescu <andrei at metalanguage.com>
   To: C++ threads standardisation <cpp-threads at decadentplace.org.uk>
   Subject: Re: [cpp-threads] C++ committee meeting in Mont Tremblant
   ...
   > Otherwise, we have to come up with another mechanism to explain when the
   > thread runtime starts and what programmers can assume about the execution
   > model. I'm totally opposed to solutions adopting artificial exceptions to
   > the standard allocation/deallocation rules, like threads cannot be
   > declared in the global scope or threads can only be declared on the
   > heap. These kinds of artificial rules are not language design or
   > extension, it is just hacking, and everyone will spot it as such.
   
   We (and I believe I can talk on behalf of everybody else in this group) 
   are in violent agreement. Of course we'd be just as abhorred. But what 
   seems to be an issue is that you seem to want to add *syntax* to solve 
   that problem, when that's emphatically not necessary.
   
   Because we waste energy on heat in uninteresting tangents related to 
   "what exactly does it mean to change a language"? :o)

I don't understand this logic. I have identify a situation with respect to
concurrency that currently has no solution, i.e., correct startup. In uC++, we
use the standard trick of creating RAII objects in each translation unit via a
required include file.  The libgcc people use the same trick to get the streams
started in <iosfwd>. This approach is fragile. The gcc compiler has:

  `init_priority (PRIORITY)'
     In Standard C++, objects defined at namespace scope are guaranteed
     to be initialized in an order in strict accordance with that of
     their definitions _in a given translation unit_.  No guarantee is
     made for initializations across translation units.  However, GNU
     C++ allows users to control the order of initialization of objects
     defined at namespace scope with the `init_priority' attribute by
     specifying a relative PRIORITY, a constant integral expression
     currently bounded between 101 and 65535 inclusive.  Lower numbers
     indicate a higher priority.

     In the following example, `A' would normally be created before
     `B', but the `init_priority' attribute has reversed that order:

          Some_Class  A  __attribute__ ((init_priority (2000)));
          Some_Class  B  __attribute__ ((init_priority (543)));

     Note that the particular values of PRIORITY do not matter; only
     their relative ordering.

but we have had problem with this working for different versions of the gcc
compiler, and it does not work for other C++ compilers. Furthermore, this
approach is also fragile because library writers have to jockey for their
priority with other developers to make things work globally.

So how can this problem be solved with a library approach and no new syntax?
Clearly, there is no mechanism in the language now that adequately provides
this capability. Therefore, no amount of effort by a library writer can cause
the compiler to generate the necessary code. So if new syntax is "emphatically"
unnecessary, please explain to me how I can solve this problem, and I will
change uC++ immediately to use your approach. Otherwise, I will continue to
waste the energy of this group suggesting language changes, many of which may
involve syntactic changes to the language.

Until someone can generate a proof that concurrency can be added without
changing the language and adding new syntax, we should assume the oppose. I
have strong empirical evidence to suggest that syntactic changes are necessary.