Messages in this thread | | | Subject | Re: [PATCH RFC tip/core/rcu] rcu: direct algorithmic SRCU implementation | From | Peter Zijlstra <> | Date | Thu, 16 Feb 2012 13:44:41 +0100 |
| |
On Thu, 2012-02-16 at 07:18 -0500, Mathieu Desnoyers wrote: > > Hrm, I think we'd need a little more than just lock/unlock ordering > guarantees. Let's consider the following, where the stores would be > expected to be seen as "store A before store B" by CPU 2 > > CPU 0 CPU 1 CPU 2 > > load B, smp_rmb, load A in loop, > expecting that when updated A is > observed, B is always observed as > updated too. > store A > (lock is permeable: > outside can leak > inside) > lock(rq->lock) > > -> migration -> > > unlock(rq->lock) > (lock is permeable: > outside can leak inside) > store B
You got the pairing the wrong way around, I suggested:
store A
switch-out UNLOCK
-> migration ->
switch-in LOCK
store B
While both LOCK and UNLOCK are semi-permeable, A won't pass the UNLOCK and B won't pass the LOCK.
Yes, A can pass switch-out LOCK, but that doesn't matter much since the switch-in cannot happen until we've passed UNLOCK.
And yes B can pass switch-in UNLOCK, but again, I can't see that being a problem since the LOCK will avoid it being visible before A.
> Does that make sense, or should I get my first morning coffee ? :)
Probably.. but that's not saying I'm not wrong ;-)
| |