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

[Doug Lea]

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.

Well, in Java we learned to cheat. JSR166 (concurrency), JSR51(nio),
and others changed the language by defining operations that cannot
be explained in terms of other language features (nothing exotic, just
things like CAS and park/unpark (primitive thread-blocking)) which
forces JVMs to specially recognize ordinary-looking method calls to
implement as "intrinsics". I think the same kind of cheating applies
here. In this case the difference between syntax and library amounts
to how pretty you'd like user code to be. We'd all like it as pretty as
it can be, but for stuff like atomics with a high geek-factor anyway,
it's not a high priority. For other aspects, there might be a
stronger case.

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

This is a great point, that we've so far neglected. As far as I can see,
without some major surgery, the only well-defined threads will be those
constructed after commencement of main(). But I guess saying even this
is premature -- without knowing what a C++ "thread" is yet, it's hard
to say how well-defined it will be in any context.

-Doug