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

[Boehm, Hans]

If you disagree with the direction in which this is going, please make a
(at least somewhat) specific proposal, ideally both here and to the C++
committee.  It's not hard to get a paper into the C++ committee mailing.
It's even easier to post something here.

Exaggerating a bit, my expression here is that we have a lot of
different opinions on the thread API issues, but we don't seem to be
able to agree on much other than the fact that most of the other
proposals are wrong.  I'd like to see more discussion of specific
problems and, even better, solutions.

The C++ committee was aware of vague allegations that Boost threads are
bad, but in the absence of actual arguments to that effect that didn't,
and shouldn't, carry much weight.  In particular, it would be nice to
know whether these are objections to specific fixable API issues, a
general feeling that the interface is at too low a level, or something
else.  If someone is familiar with the issues, and wants to write those
up, I think that would be a significant contribution.  Given that Boost
has been available for a while, and it has two commercial variants in
addition to the open source one, seems to make the natural front-runner
here.

At the risk of repetition, here are my views:

1) I continue to think that the memory model should be at least my
number one priority.  As long as compilers can effectively introduce
data races at will, there is no hope of writing ANY reliable
multithreaded code.  There is more of a discussion of this in the paper
we recently submitted to the C committee.
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1131.pdf)  I am mostly
concerned with the semantics of race-free programs here which, by
themselves, are not a trivial issue.

If Fortran 2003 has something to add, I'd love to know about it.  A
quick look at the standard didn't give me the impression that it
addresses threads at all.

2) I agree with Nick that we will end up relying on the sequencing
specification for sequential code, i.e. sequence points.  I'm also not
too happy with the way that currently reads in the C++ standard, though
others seem to be more satisfied with it.  I'd love to see improvements
there, but I'm not sure we will have the time to address much of that.

3) I also think that the atomics library and intentional data races are,
by themselves, a less important consideration.  The problem is that they
severely impact the memory model, and hence I don't think we can
postpone the issue.  Experience with CLI strongly suggests that the
issue cannot be avoided.  All large existing code bases seem to contain
tons of data races, often due to double-checked locking.  We at least
have to give people a practical way to fix their code.

4) I'm actually reasonably happy with pthread-like synchronization
facilities.  Though I don't agree 100%, there seems to be clear support
constructor/destructor-based lock acquisition for C++, and that's a
trivial wrapper around pthread-like facilities.  (I have some issues
some of the detailed specifications, or absence thereof, and some of the
implementations behind those interfaces.  But I think that is mostly due
to the attempt to satisfy too many constituencies at once, an issue
which we will also be unable to avoid, I suspect.  And I don't think any
of this is fundamental.)

5) I would not be happy with a facility that restricted lock acquisition
to function boundaries or forced me into per-object locks.  Similar
opinions were expressed by others on the committee.  There are many
algorithms for which that is insufficient.

6) It would be really nice to address the
exception/cancellation/destructor mess.  This probably affects
considerably more code in practice than the thread creation API.

7) I personally don't care that much what the thread creation API/syntax
looks like, but we do need one.

8) I think we cannot just propose something like uC++, since it contains
other features (coroutines in particular) that would be unlikely to be
accepted.

9) Something like MPI is a fine approach to writing certain kinds of
code, but is out of scope for this discussion.  We are dealing with
shared memory concurrency.

10) We are also not addressing multi-process, partial shared-memory
concurrency along the lines of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1834.html

There are also strong arguments that this is useful, and our memory
model and atomic operations will help it along.  But this approach
inherently breaks so many standard C++ mechanisms (function pointers,
virtual functions, and hence most of the standard library) that we
really don't have time to go there.

Hans

-- 
cpp-threads mailing list
cpp-threads at decadentplace.org.uk
http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decadentplace.org.uk