[lkml]   [2007]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] make cancel_rearming_delayed_work() reliable
    On Tue, May 15, 2007 at 10:26:41AM +0200, Tejun Heo wrote:
    > Oleg Nesterov wrote:
    > > So, try_to_grab_pending() should check "VALID && pointers equal" atomically.
    > > We can't do "if (VALID && cwq == get_wq_data(work))". We should do something
    > > like this
    > >
    > > (((long)cwq) | VALID | PENDING) == atomic_long_read(&work->data)
    > >
    > > Yes? I need to think more about this.
    > I don't think the test for PENDING should be atomic too. cwq pointer
    > and VALID is one package. PENDING lives its own life as a atomic bit
    > switch.


    I've overheared somebody is talking about my favorite 2-nd bit!
    Probably I miss many points (your talk isn't the most clear),
    but I wonder if this bit couldn't be used otherwise: try_to_grab_
    sets the bit - others know cancel is pending, so don't disturb:
    e.g. insert_work doesn't queue (at least after works' cpu change,
    which seems to be the main problem here). Probably there is
    no reason to test this bit in all places - only in the most
    problematic; so, in insert_work maybe only after checking
    the cpu was changed. If this way is possible, we could avoid
    setting the VALID bit when not needed (no cancel pending). Maybe
    we could also think about some form of cooperation - e.g. clearing
    of this or other bit to ack the work was catched - of course
    this last thing could be too much, so not necessarily now.

    Jarek P.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-15 15:05    [W:0.021 / U:15.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site