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

[Andrei Alexandrescu]

I think that's a great outcome, Hans, and I'd like to congratulate you 
for so graciously taking ownership of this important project.

I'm not sure I understand this part:

 > There seemed to be some preference to go back to something
 > like the member-template formulation of the C++ API, to ensure that the
 > ordering constraints are guaranteed to be statically known (I guess that
 > leaving them part of the operation names would also satisfy this
 > constraint.)

What's the member-template formulation?

I believe that the important tasks lying ahead are:

1. Define the memory model

2. Establish the atomic operations interface

3. Develop the low- and mid-level API

4. Leave room for future things (such as machine-wide atomic sections)?

If (3) is modeled after Boost, I am worried that it will be quite 
clunky. Sigh. Kevlin, Kevlin, where are you. Then, I'm not sure why the 
low-level API would be necessary it the mid-level API is well-designed 
(which implies it doesn't introduce inefficiencies or awkwardnesses that 
would force one to go down to unprotected C-style APIs).



Andrei

Hans Boehm wrote:
> I attended most of the meeting in Mont Tremblant.  I presented a
> status update to the committee, and solicited feedback on a number
> of issues.  Here is a quick report.
> 
> In general we received very strong encouragement to continue and to
> complete this effort asap.
> 
> Lawrence Crowl presented a proposal for C-compatible syntax extensions to
> support thread creation, locks, condition variables, and atomic
> operations. My reading is that, in spite of the fact that syntax
> extensions make some things a bit easier, the committee would prefer to go
> with library extensions for all of these.  Limited syntax extensions
> seemed acceptable in cases where there is a demonstrable benefit, but they
> generally seem to be considered suspect, primarily since they make it much
> harder to construct prototypes.
> 
> Many participants seemed to, perhaps tentatively, favor a solution that
> includes a C-level threads API (preferably by requiring pthreads, or
> possibly a subset that is efficiently implementable on Windows, if that is
> confirmed to be an issue), as well as a medium-level API based on Boost
> threads.  There seemed to be somewhat of a consensus that a higher level
> API would be nice, but was unlikely to be designed, implemented, and
> generate enough practical experience in time for the next C++ standard,
> especially since it was unclear that there was an active effort along
> those lines.
> 
> We discussed the atomic operations interface in a relatively small group.
> Among that group, people seemed to favor a similarly structured interface,
> with a C-level API (fixed set of types, ordering constraints part of
> operation names) at the bottom, with a higher-level C++ API implemented on
> top of it.  There seemed to be some preference to go back to something
> like the member-template formulation of the C++ API, to ensure that the
> ordering constraints are guaranteed to be statically known (I guess that
> leaving them part of the operation names would also satisfy this
> constraint.) This makes sense to me if you anticipate optimizing compilers
> that try to allow some compiler reordering around these calls, though I
> think it's not fundamentally impossible to have compilers handle the other
> version.
> 
> There was a desire to make the memory model spec self-contained and
> reasonably precise, if there is any way to accomplish that.  We can
> apparently refer to other standards published by some established
> standards organizations, but refering to the JLS is not an option.
> 
> Hans
> 
> 
>