Separating the memory model and the library

[Andrei Alexandrescu]

I agree with Doug. Well put.

One delicate issue we'd need to address, however, will be this: If I 
understand correctly, we can develop a memory model that will be 
detailed and potent enough to implement client-level threading 
primitives (such as mutexes etc.) Yet, with many systems it is as good 
or better to use the system-provided synchronization primitives. The 
delicate issue, I believe, will be to provide a memory model that will 
allow system-implemented primitives to mesh in seamlessly, as well as 
allowing users to implement their own if they need to.


Andrei

Doug Lea wrote:
> Adding Maged would be fine.
> 
> 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. 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 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.
> 
> -Doug
> 
>