Michael Maged

[Doug Lea]

Andrei:

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

Yes. The issue of how to qualify/specify opaque functions becomes
critical here. It would be nice if it were the case that say a lock()
function could be marked in some way so as to be known to act an
acquire wrt the memory model, and so on.


Kevlin:

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

Right. That's why Peter said "thanks but no thanks" about all this to
me.  He did promise to collect up all of his problems he's faced over
the years with basic memory semantics etc in C++ compilers and send to
me though.

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

Good question. The dead minimum for (1) seems to be to define a Thread
class, with ways to create, start, block, unblock, block-with-timeout,
detect termination, and query status. You could then in principle
build everything in (2), not that most people would want to --
existing stuff must be able to comply.  Can this be done in a way that
everyone is guaranteed to love, or at least tolerate?

-Doug