[lkml]   [2005]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/2] del_timer_sync: proof of concept
    Andrew Morton wrote:
    > If we're prepared to rule that a timer handler is not allowed to do
    > add_timer_on() then a recurring timer is permanently pinned to a CPU, isn't
    > it?
    > That should make things simpler?

    I think that current inplementation of del_timer_sync() don't like
    add_timer_on() too.

    Consider the timer running on CPU_0. It sets timer->expires = jiffies,
    and calls add_timer_on(1). Now it is possible that local timer interrupt
    on CPU_1 happens and starts that timer before timer->function returns on

    del_timer_sync() detects that timer is running on CPU_0, waits while
    ->running_timer == timer, and returns. The timer still runs on CPU_1.

    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: 2005-03-22 14:11    [W:0.019 / U:105.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site