On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
> Paul E. McKenney wrote:
> >On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
> >> If you're depending on volatile writes
> >>being visible to other CPUs, you're screwed either way, because the CPU
> >>can hold that data in cache as long as it wants before it writes it to
> >>memory. When this finally does happen, it will happen atomically, which
> >>is all that atomic_set guarantees. If you need to guarantee that the
> >>value is written to memory at a particular time in your execution
> >>sequence, you either have to read it from memory to force the compiler to
> >>store it first (and a volatile cast in atomic_read will suffice for this)
> >>or you have to use LOCK_PREFIX instructions which will invalidate remote
> >>cache lines containing the same variable. This patch doesn't change
> >>either of these cases.
> >
> >The case that it -can- change is interactions with interrupt handlers.
> >And NMI/SMI handlers, for that matter.
>
> You have a point here, but only if you can guarantee that the interrupt
> handler is running on a processor sharing the cache that has the
> not-yet-written volatile value. That implies a strictly non-SMP
> architecture. At the moment, none of those have volatile in their
> declaration of atomic_t, so this patch can't break any of them.
This can also happen when using per-CPU variables. And there are a
number of per-CPU variables that are either atomic themselves or are
structures containing atomic fields.
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
