[cpp-threads] Berlin meeting

[Boehm, Hans]

Here's a quick overview of the concurrency discussions at the Berlin C++
standardization meeting a week and half ago.  This is probably warped by
my perspective, and by the fact that I had to leave half a day early.

The long-standing "evolution" subgroup was divided into several smaller
subsubgroups, of which the concurrency & GC group was the largest
(initially about 15 participants).  (GC is mostly unrelated, but was put
in the same group due to participant overlap.)  I spent most of my time
in this subsubgroup.

Memory model:

There seemed to be general, though tentative, agreement that we're on
the right path.  I emphasized that we would be taking a small
optimization hit as a result of this, and that we would effectively be
constraining future architectures.  The most serious concerns seemed to
be related to the bit-field rules.  The concerns were on both sides:

- Are the rules too stringent for effective optimization?
- Are the rules too relaxed for code that uses bit-fields for space
efficiency?  Should there be language support to request
compare-and-swap updating of bit-fields?

Further meetings will be scheduled to discuss some of these in detail
with individual groups.  But my general sense is that we will probably
end up sticking mostly with the current proposal.

Clark and I hope to produce proposed text for the standard shortly.

There was discussion of Clark Nelson's sequence point proposal.  From my
perspective, this was very beneficial, in that I think I now understand
the intent of the current standard, mostly as a result of a very helpful
group discussion with Tom Plum.  The crucial insight from my perspective
is that there is no single partial ordering that reflects the "is
sequenced before" constraint in C++.  An execution essentially first
picks an argument evaluation order (which may differ for each execution
of a function call).  Once you know the argument evaluation order, you
can then define an "is sequenced before" relation.

I'm actually not quite sure where this left Clark's proposal.  I would
personally still like to see this cleaned up in the standard.  But since
we now understand the intent, I think we can rephrase the model even if
it's not cleaned up.  And there seemed to be substantial "don't go
there" sentiment among the committee.

Atomics interface:

We probably engaged in more committee design here than perhaps we should
have.  On the other hand, we did end up with some significant revisions
and improvements to the prior proposal.  I tried to reflect them on the
web site at http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ .  There
was some discussion of static vs. dynamic feature tests.  After thinking
about it, I think you want them to be mostly "dynamic", since many
executables are designed to support architectural variants with
different atomic operations support (e.g. X86, X86/64, ...)

Threads API (or syntax):

We spent a fair amount of time discussing this, in large part from first
principles.  The discussion was still in progress when I left, but
seemed to be starting to converge, at least slightly.  Lawrence Crowl
ran some of this discussion, including the final piece, so I'm not sure
about the final status.  He may be able to comment and/or submit a
summary as a committee paper.

Rest of C++ library:

I think there is a growing realization that there is a lot of work to be
done.  And I'm afraid that some of the details here are actually
critical, in that they may force a real ABI change.  (The memory model
changes should encourage recompilation anyway, since you might otherwise
spend time debugging old compiler misfeatures.  But I don't think they
require it for working code.  But I don't know whether we really can, or
want to, save, for example, the COW support in the basic_string spec.)

(I don't think C++ is anywhere near alone here.  Most other library
specs also seem to be rather sparse when it comes to specifying thread
semantics, e.g. the effects on inter-thread visibility.)

Hans