[cpp-threads] OpenMP Memory Model

Bronis R. de Supinski bronis at llnl.gov
Fri Apr 14 22:11:08 BST 2006


Hans:

First a couple general comments. You mentioned a proposed C++
memory model. Is there a draft or something available for review?
I would be very interested in looking at it if possible. Also,
I think we have generated interest in looking at the OpenMP memory
model as part of the OpenMP 3.0 specification process. If that
does happen, would you be interested in participating in the
discussions? If so, let me know and I will let you know when
they are scheduled.

Next, I agree with Greg's responses. I have a couple additional
comments/questions below as well.

[snip]

> > 4) The notion of atomic operations seems quite different, in that
> >
> >   (a) There is no need to label reads of atomic variables specially.  An
> > ordinary read that races with an atomic write is OK.  I don't think this
> > is a good design decision, but it seems to be the way OpenMP works.

Indeed it is. I agree it is odd. If you have any examples for
which this creates difficulty, they would be useful.

> >   (b) Atomic operations are what we would call "unordered".  Given that
> > the corresponding reads are not special and hence unordered, this
> > probably doesn't lose anything.
> >
> > I expect the resulting notion of atomics usually requires lots of
> > explicit "flush"es, which I think are expensive to implement on
> > architectures like X86 or IA64, since I think they require StoreLoad
> > ordering.

Yes, many explicit flushes can be required. I find the atomic directive
generally problematic. However, others are arguing for relaxing some of
the other odd restrictions on them (specifically that they apply to only
the written variable and it must also be read in the code block). I
expect the memory model discussions to touch on these questions.

[snip]

> > If so, I think that would get us back to the "reads kill" problem in the
> > original Java memory model, which wasn't a good idea, mostly because it
> > seemed to be too expensive to get anyone to bother to implement
> > correctly.

Interesting. Strictly speaking, it is not clear whether the OpenMP 2.5
specification memory model requires this "reads kill" behavior. Rather,
Greg and I felt it would be useful and seemed to conform to the intent
of the model. Any additional information you could provide on whether
it proves difficult to work without it or why it was hard to get anyone
to implement it correctly would be useful.

Thanks,

Bronis




More information about the cpp-threads mailing list