Implementation of memory model

[Boehm, Hans]

Andrei, Ben -

I'm not sure exactly what kind of implementation effort we're talking
about here.

I think we're likely to come up with a memory model
that would be satisfied by the current g++ -O0 on X86, IA64,
SPARC TSO or PA (and probably many other compilers and platforms
at minimal optimization).  Thus I expect that for this part
we'll have an existence proof without doing any real work.
We'll of course still need the opinions of compiler
implementers as to the effect on current and future optimizations,
though I think several of us have some reasonable understanding
of those issues.  It would be good to have an optimizer that
obeys whatever rules we propose, but I'm not sure it's either
essential or terribly convincing, since I think any effect is
likely to be very compiler- and architecture-dependent.

We will of course need an implementation of the library components.
But I'd be unhappy of that took a lot of new work.  I would guess
that, for compilers that currently provide access to atomic operations
and barriers via intrinsics or inline assembly, it should be possible
to make a first pass at this without touching the compiler.

Hans 

> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrei at metalanguage.com]
> Sent: Friday, September 17, 2004 1:36 AM
> To: Ben Hutchings
> Cc: Hans Boehm; Kevlin Henney; Bill Pugh; Douglas C. Schmidt; Doug Lea
> Subject: Re: Implementation of memory model
> 
> 
> My hope is to convince Howard Hinnant to join us by using beer as
> bribe.
> 
> Andrei
> 
> Thursday, September 16, 2004, 5:23:04 PM, you wrote:
> 
> > I expect that it will be necessary to get some 
> implementation experience
> > with any proposed memory model in order to produce a 
> practical proposal
> > that implementers will support and will adhere to if and 
> when it becomes
> > part of the next standard (or even before then).  It will 
> surely benefit
> > from Bill and Doug's experience with defining the Java 
> memory model, but
> > there are issues with C++ that don't arise in Java.
> 
> > Now correct me if I'm wrong, but I don't think any of you 
> are involved
> > in implementation of C++ compilers.  So I think we should 
> try to get at
> > least one implementer involved in this.  Perhaps you 
> already planned to
> > do this at the Redmond meeting, Andrei?  Alternately it may 
> be possible
> > for one or more of us to try out changes to GCC or EDG's 
> C++ compiler,
> > though I suspect that's much easier said than done.
> 
> > Ben.
>