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

[Peter A. Buhr]

   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.

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%?

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. 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. I've also developed
and used medium-level thread libraries and they are inadequate, too. Let's get
with the program, and figure out what regular programmers and compiler writers
need to aid in the development of large, complex, concurrent applications in a
reasonable period of time. I'm sorry but double-check locking is simply not on
the horizon at this level.

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

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?

Yours, getting near the end of his thread,
Peter Buhr