Re: Intermediate report for AIX 5L port

> Thomas Lockhart <lockhart@fourpalms.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@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