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

[Peter A. Buhr]

Sorry for going walk-about; it's been a busy week. I'll try to answer all the
replies to my initial message but please be patient as I'm as busy as the rest
of you.

   The term that is normally used -- "adding threads via a library" -- is 
   perhaps too loose. I think that "presenting threads via a library" is 
   another way of looking it.

I guess I don't appreciate the subtle semantic difference. To me it's either a
library approach or it's a language approach, and never the twain shall meet.
It's like being pregnant: either you are or you are not, and you accept the
consequences of each case.

   Of course, such a library-styled solution is going to be limited in what 
   it can achieve, eg introducing monitor objects or a rendezvous mechanism 
   is less than transparent.

But this statement is an admission of failure before we begin. I see no reason
to accept a starting position that involves a complete compromise of what many
of us believe and what most programmers down the road would want for
concurrency in C++.

   But I am not sure that the committee has a general appetite for language
   changes,

It is not our responsibility to adjust what we believe to meet the political
agenda of the standards committee. It should be our job to do what we think is
right in terms of current knowledge in the area, and what we believe is best
for C++ in the long run. We should be pro-active and push the standards
committee as far as possible, backing off only when we believe sufficient good
science has been accepted. We are the experts, and they should listen to what
we have to say. If they choose to ignore us, that's their loss.

   judging by what I am hearing about feedback on proposed Daveed Vandevoorde's
   module mechanism.

So let's look closely at this point because it has significant ramifications
with respect to concurrency. One of the main purposes for modules is to provide
boot-time initialization for an application and to perform this initialization
in the correct order.  For example, Ada packages provides this capability and
the compiler performs a transitive closure over the application package-set to
determine the package dependencies, and hence, the correct order of package
initializations.  Now this is of particular importance for concurrency because
the boot-order needs to be defined so the runtime thread-system is started soon
enough but not too soon (or not at all if it isn't needed). Since C++ allows
global declarations, it is possible to create an object with a thread during
global construction and have it complete execution before the program "main"
routine even starts. Hence, the thread runtime must be started before any user
objects are created. How is this going to be accomplished? Currently,
thread-library developers (like myself) use egregious hacks and programmer
convention to get things started in the correct order, but it's just luck that
it works most of the time. Now that's simply not good enough and it must be
addressed. If it can be addressed via a proper module system, we should be
backing this proposal as part of what we do.

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.

This issue is just one example of many high-level issues we should be
discussing as part of this subcommittee. Concurrency needs a strong memory
model, but it needs a lot more, so why aren't we actively talking about the
"other" stuff, too?