Dan Malek writes: > It needs to be volatile as a means of synchronization between the interrupt > handler that will set the flags and a normal thread of execution that will > test them. The normal thread would cache a value in a register and never > look at any updates that occurred as part of an interrupt.
If we have a variable which is being updated both by the mainline and an interrupt handler, then we should be using some explicit synchronization (e.g. disabling interrupts around the region where we do the update) or else we should be using atomic operations. Just declaring it volatile is *not* enough, because, clearly, something like "a &= ~1;" in the mainline will do a load and a store and that will create a window where an update done by an interrupt handler will get ignored. In general we should have a spinlock and do spin_lock_irqsave / spin_unlock_irqrestore around the update. If the code will never be used on an SMP system then we can reduce that to save_flags/cli and restore_flags. Note that __cli et al. include a gcc memory barrier precisely because they are often used to protect accesses to variables that are accessed both by mainline and interrupt-level code. Paul. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
