[lkml]   [2012]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC tip/core/rcu] rcu: direct algorithmic SRCU implementation
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


-> migration ->


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 ;-)

 \ /
  Last update: 2012-02-16 13:47    [W:0.099 / U:1.864 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site