Re: Intermediate report for AIX 5L port

> Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> >> Declaring the lock pointer "volatile" seems to prevent this misbehavior.
>
> > Great. That is what it is anyway, right?
>
> The reason I hadn't declared it volatile in the first place was that I
> was assuming there'd be sequence points at the spin lock and unlock
> calls. The order of operations *while holding the lock* is, and should
> be, optimizable. Pushing updates outside of the range where the lock is
> held, however, isn't cool.
>
> Now that I think a little more, I am worried about the idea that the
> same thing could potentially happen in other modules that access shared
> memory and use spinlocks to serialize the access. Perhaps the fix I
> applied was wrong, and the correct fix is to change S_LOCK from

Here is my limited experience with volatile. There was a BSD/OS
multiport card that mapped card memory to a RAM address, but the
pointers pointing to that address weren't marked as volatile. An
upgrade to a better compiler caused the driver to fail, and I finally
figured out why. Marking them as volatile fixed it.

Seems this is the same case. We are not pointing to memory on a card
but to shared memory which can change on its own, hence it is volatile.

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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026