On Tue, Oct 30, 2007 at 07:50:04 -0700, Ian Lance Taylor wrote:
> Tomash Brechko <[EMAIL PROTECTED]> writes:
>
> > Even if we put aside the fact that there's no such membarrier()
> > equivalent in POSIX bindings, this won't help.
>
> In POSIX, any mutex function must be a membarrier. For example, on
> x86, mutex lock and unlock more or less have to execute the mfence
> instruction. If they don't, the program can see inconsistent data
> structures despite the mutex operations.
Yes, but you don't imply I should write
if (condition) {
*p = value;
pthread_mutex_lock(&dummy):
pthread_mutex_unlock(&dummy):
}
just to trigger it.
> > 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.
> 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?
--
Tomash Brechko
