> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom, I assume what you are saying is that the access to the spinlocks,
> > already marked as volatile, should have prevented any code from
> > migrating over those locks. I guess my big question is does any
> > volatile access prevent optimization of other variables across that
> > volatiles access? I didn't think that was guaranteed.
>
> After eyeballing the C spec some more, I think you might be right.
> If that's the correct reading then it is indeed necessary for lwlock.c
> to mark the whole lock structure as volatile, not only the spinlock
> fields.
OK.
> However, if that's true then (a) 7.2 has three other modules that are
> potentially vulnerable to similar problems; (b) prior releases had
That was going to be my next question.
> many more places that were potentially vulnerable --- ie, all the
> modules that used to use spinlocks directly and now use LWLocks.
> If this sort of behavior is allowed, ISTM we should have been seeing
> major instability on lots of SMP machines.
Again, a good question. No idea.
Here is a more general question:
If you do:
get lock;a=4release lock;
Can the compiler reorder that to:
a=4get lock;release lock;
It can see the lock values don't have any effect on 'a'. What actually
does keep this stuff from moving around?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026