lkml.org 
[lkml]   [2009]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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:

spin_lock(&hash_lock);

if (unlikely(hash_update_active)) {
spin_unlock(&hash_lock);
wait_event_(un)interruptible(&hash_wq, !hash_update_active);
spin_lock(&hash_lock);
}
resize side:

spin_lock(&hash_lock);
hash_update_active = 1;
....
spin_unlock(&hash_lock);
synchronize_rcu();
hash_update_active = 0;
wake_up(&hash_wq);
Thanks,

tglx


\
 
 \ /
  Last update: 2009-12-18 18:17    [from the cache]
©2003-2011 Jasper Spaans