[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.028 / U:3.804 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site