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

[Hans Boehm]

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