lkml.org 
[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
    From
    Date
    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 ;-)


    \
     
     \ /
      Last update: 2012-02-16 13:47    [W:0.023 / U:64.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site