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

[Nick Maclaren]

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

I really am trying to make time.  I am somewhat handicapped by a poor
(like, minimal) knowledge of C++, but my interests are in the models
and the principles.

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

Yes.  And I can witness that this is a real problem in practice.

> I am mostly
> concerned with the semantics of race-free programs here which, by
> themselves, are not a trivial issue.

I promise to try to write something on the various issues involved
that can imply serialisation.  This is something that causes havoc in
HPC - think of thread A writing to a FIFO read by thread B - that
clearly causes serialisation in time, but does it do so in the
language?  Not to say the issue of pairwise versus global consistency,
clock models (don't get me started!) and so on.

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

It doesn't.  I was referring to ASYNCHRONOUS and VOLATILE, which at
least make some kind of sense - unlike C volatile!

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

There's more to it than just sequence points - a LOT more :-(

Let's ignore the minor (!) detail that the specification of C sequence
points is hopelessly broken (and I don't think that C++ is much better),
there is also the issue of when 'external' events cause serialisation
and how they come in.  See above.

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

Agreed.

> 4) I'm actually reasonably happy with pthread-like synchronization
> facilities.  ...

They aren't wonderful, but aren't the aspects that are broken.  I, too,
can live with them.

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

Yes.

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

It is CRITICAL to address it, even if certain things are forbidden
because of pressure of time/effort/brains.

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

Yes.

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

Yes.  It was an example of a clean, low-level, library-based API.  No
more.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

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