Tomash Brechko <[EMAIL PROTECTED]> writes:
> > > if (condition) {
> > > *p = value;
> > > membarrier();
> > > } else {
> > > membarrier();
> > > }
> > >
> > > But this is the same as
> > >
> > > if (condition)
> > > *p = value;
> > > membarrier();
> >
> > No, it isn't. If membarrier is not a general function call, then it
> > has to be a magic function. In gcc it is implemented using a volatile
> > asm.
>
> I didn't get your point, but probably you didn't get my either. I was
> talking about memory barriers as a whole, not a particular
> implementation in GCC. And my point is that you are free to inject
> them wherever you like. This will affect performance, but not
> correctness. Hence you can't be sure membarrier() won't be moved from
> the condition.
My point is that for a memory barrier to work at all, it has to be
magic. And if it is magic, then it can not be moved from the
condition.
To put it another way, if you can move the memory barrier from the
condition, then it is not a memory barrier after all.
> > Note that I've committed my patch to avoid speculative stores to all
> > active branches, so this particular case should be a non-issue going
> > forward. However, we all are going to have to take a careful look at
> > gcc to make sure that it generally conforms to the C++0x memory model.
>
> I'm not against ending this discussion. As I understand the patch
> (and I don't grok GCC internals), it fixes both read-only memory case,
> and race case. But it doesn't try to preserve the optimization in the
> form that was suggested by Michael Matz (i.e. to use pointer to dummy
> object on the stack), right?
I don't know which suggestion you are referring to. The patch I wrote
will retain the optimization in the case where the memory location is
unconditionally written later in the function. This is most relevant
in that the optimization can take place in a loop, if somewhere after
the loop the memory location is unconditionally written.
Ian
