(original) (raw)

Hmm, so no barriers \*at all\* if IRIW is true, as-if these are plain stores? That does seem wrong.

On Tue, Jun 23, 2015 at 12:29 PM, Roland Westrelin <roland.westrelin@oracle.com> wrote:

> So what does the graph look like for this example?

I haven’t checked but I would expect:

...->MB->->ST(y=2)->MB->ST(x=1)->MB->ST(y=1)->...

if support\_IRIW\_for\_not\_multiple\_copy\_atomic\_cpu is false

...->ST(y=2)->ST(y=1)->...
...->ST(x=1)->...

otherwise

Roland.

\>
\> sent from my phone
\>
\> On Jun 23, 2015 6:50 AM, "Roland Westrelin" <roland.westrelin@oracle.com> wrote:
\>
\> >> What about
\> >>
\> >> volatile int y;
\> >> volatile int x;
\> >>
\> >> y=1
\> >> x=1
\> >> y=2
\> >>
\> >> transformed to:
\> >>
\> >> x=1
\> >> y=2
\> >>
\> >> ?
\> >
\> > I think this is not allowed, since operations over "x" get tied up in
\> > the synchronization order.
\>
\> Thanks. Then for support\_IRIW\_for\_not\_multiple\_copy\_atomic\_cpu true, I don’t see how incorrect reordering is prevented.
\>
\> Roland.