[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: spinlock which can morph into a mutex
    On Fri, 18 Dec 2009, Miquel van Smoorenburg wrote:

    > I'm trying to implement a dynamically resizable hashtable, and
    > I have found that after resizing the table I need to call
    > synchronize_rcu() and finish up before letting other writers
    > (inserts, deletes) access the table.
    > Ofcourse during the hashtable update a spinlock is held to
    > exclude the other writers. But I cannot hold this spinlock over
    > synchronize_rcu(), yet the other writers still need to be excluded.
    > So I probably need a mutex instead of a spinlock, but I want to
    > keep minimal overhead for the common case (when no resizing is in
    > progress). I think I need a spinlock that can morph into a mutex ..

    Is the writer frequency and the possible contention so high that you
    need a spinlock at all ?

    > I was thinking about using something like the code below.
    > It is sortof like a spinlock, but it's ofcourse less fair
    > than actual ticketed spinlocks.
    > I'm working off 2.6.27 at the moment, but I noticed that in
    > 2.6.28 adaptive spinning was introduced for mutexes. Is the
    > approach below still worth it with adaptive spinning or could
    > I just convert the spinlocks to mutexes with minimal extra overhead ?

    Test it :)

    If the mutex is still to heavy weight for you, then you can solve it
    without implementing another weird concurrency control:

    writer side:


    if (unlikely(hash_update_active)) {
    wait_event_(un)interruptible(&hash_wq, !hash_update_active);

    resize side:

    hash_update_active = 1;
    hash_update_active = 0;



     \ /
      Last update: 2009-12-18 18:17    [W:2.931 / U:0.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site