> 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