Michael Maged

[Kevlin Henney]

In message <16733.17809.402132.611641 at altair.cs.oswego.edu>, Doug Lea 
<dl at cs.oswego.edu> writes
>
>But the other exchanges convince me to switch from being agnostic
>about combining memory model (+atomics) vs library in one proposal to
>now agreeing with Hans that they ought to be separated.  There is too
>much religious fervor out there about the best way to support
>medium-level concurrency control.

Agreed. There is no shortage of competing library models out there, and 
while there are some commonalities (eg the emerged consensus that 
function objects are the medium for expressing the threading message) 
there are also some curiosities (eg some cyclic dependencies in the 
Boost synchronisation primitives).

>I was further reminded of this after
>a couple of recent exchanges with Peter Buhr, who has been working on
>concurrency in C++ for 15 years now, and who has some very strong
>opinions about it. (See http://plg.uwaterloo.ca/~pabuhr/ papers on
>uC++). He liked the MM aspects of proposal but hated the idea
>of standardizing library without further syntactic/languagec support.

The odds of standardising a model that required language extensions 
rather than a library-based approach are, to be frank, vanishingly 
small.

>The memory model parts might still have some residual controversy (as
>indicated in some of Jim Rogers remarks), but there seems a good
>chance they could quickly succeed. The library part could still try to
>proceed in a compatible way, but there is less risk losing everything
>in case it stalls.

To hark back to an earlier posting I made (my original library 
requirements posting, IIRC), there are three levels to standardise:

(0) The memory model, which would also include any library elements 
required to express such concepts as memory barriers and atomic actions.

(1) Primitive library threading and synchronisation features at a level 
above C APIs, but without loss of appropriate expressiveness. This would 
depend, for its implementation and behaviour, on (0).

(2) Higher-level threading and synchronisation facilities, such as 
thread pools or queues. This should be in terms of features defined at 
(1).

It makes sense to propose (0) separately from (1) and (2). Whether (1) 
and (2) should be combined is another question, but (2) would strongly 
depend on (1) so there is some motivation to do that.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________