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

[Andrei Alexandrescu]

Peter A. Buhr wrote:
>    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.

While ardor and humor are definitely to be appreciated, the comparison 
doesn't fly. A language has many features, among which syntax, 
semantics, and pragmatics. Therefore "changing the language" means 
changing any (non-empty) subset of its features.

We're talking about restraining ourselves from changing the syntax. 
That's all, and I believe it's not going to impede the flow of our 
creative juices.

>    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.

This is an extreme attitude. One that I believe is more productive is to 
  do our best at pushing as far as we can, while at the same time 
understanding their constraints. And believe me, I totally understand 
why they are refraining themselves from changing the syntax.

[more follows]

> 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.

We (and I beliebe 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.

> 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?

Because we waste energy on heat in uninteresting tangents related to 
"what exactly does it mean to change a language"? :o)


Andrei