On Fri, Nov 22, 2013 at 1:52 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> You seem to be assuming that the unlock+lock rule applies only when the
> unlock and the lock are executed by the same CPU. This is not always
> the case. For example, when the unlock and lock are operating on the
> same lock variable, the critical sections must appear to be ordered from
> the perspective of some other CPU, even when that CPU is not holding
> any lock.
Umm. Isn't that pretty much *guaranteed* by any cache-coherent locking scheme.
The unlock - by virtue of being an unlock - means that all ops within
the first critical region must be visible in the cache coherency
protocol before the unlock is visible. Same goes for the lock on the
other CPU wrt the memory accesses within that locked region.
IOW, I'd argue that any locking model that depends on cache coherency
- as opposed to some magic external locks independent of cache
coherenecy - *has* to follow the rules in that section as far as I can
see. Or it's not a locking model at all, and lets the cache accesses
leak outside of the critical section.
Btw, you can see the difference in the very next section, where you
have *non-cache-coherent* (IO) accesses. So once you have different
rules for the data and the lock accesses, you can get different
results. And yes, there have been broken SMP models (historically)
where locking was "separate" from the memory system, and you could get
coherence only by taking the right lock. But I really don't think we
care about such locking models (for memory - again, IO accesses are
different, exactly because locking and data are in different "ordering
domains").
IOW, I don't think you *can* violate that "locks vs memory accesses"
model with any system where locking is in the same ordering domain as
the data (ie we lock by using cache coherency). And locking using
cache coherency is imnsho the only valid model for SMP. No?
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>