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

[Nick Maclaren]

"Peter A. Buhr" <pabuhr at plg.uwaterloo.ca> wrote:
>
> I've been reading patiently for 6 months waiting for this subcommittee to work
> its way out of the memory-model gutter and up to something that approaches
> interesting with respect modern concurrency. I believe I even tried twice to
> start a high-level discussion and got no response. While I believe a good
> memory model is important, it is only 2% of what regular programmers need to
> develop good, reliable, concurrent application. So what about the other 98%?

Well, speaking as someone who has been beating my head against these areas
in the context of many languages and systems for 25+ years, I agree that
you are right about the 2% and 98%.  HOWEVER:

There are some aspects that do need integration.  E.g. the sequencing
model (INCLUDING the sequencing of interrupts) is inseparable from the
memory model, as anyone who has experience of implementing run-time
systems with good parallel/interrupt support can witness.

There are some aspects which are so demented by brain-rot over the past
decades that no mere mortal can resolve them.  E.g. the utter lunacies
involving the categorisation of exceptions, where 'modern' hardware,
operating system and language systems use fundamentally incompatible
models, all of which are irredeemably broken.

There are some aspects that can be separated off.  E.g. the SYNTAX of
95% of the parallelisation primitives.

> I interpret these two paragraphs as saying that this subcommittee does not
> have the backbone to take a strong position to the standards committee
> stating that the only correct approach to modern concurrency is to proved
> integrated, high-level mechanisms into the language.

That is false.  It IS true that the semantics need to be integrated, but
there are many ways of handling concurrency.  Modulo the lack of a memory
model (which, in context, is not catastrophic - and is largely resolved
in Fortran 2003), MPI is an example of a good low-level, library-based
solution.  There have been other good, similar solutions.

>  Only people who do not write
> concurrent programs would suggest pthreads (C-level threads API) as a good
> approach to concurrency.  I've been there, done that, and it's crap. I've
> never met a regular application programmer that likes pthreads. ...

You are overselling pthreads.  It is worse than that.  MUCH worse.

> If the goal of this committee is to codify pthreads and the boost thread
> library into C++, than this is a waste of time, and the results will be wholly
> inadequate.

That is unquestionably true, except that the term is catastrophic.

> Do you people really understand what the larger issues are with
> respect to developing a full-blown concurrent language? So far, I have read
> nothing to suggest that you do.

I am not sure that I do, but I believe that I am confused more widely
and at a deeper level than most people :-)

> We are suppose to be the experts. If we take a strong stand on high-level
> concurrency, the standards committee will listen. If we suggest the status
> quo, the committee will hear that, too. So what's it going to be boy, yes
> or no?

Or, in my case, "yes" to the semantics and "no" to the syntax :-)

> Yours, getting near the end of his thread,

Yours, getting near retirement :-)


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