public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, miquels@cistron.nl
Subject: spinlock which can morph into a mutex
Date: Fri, 18 Dec 2009 15:30:35 +0100	[thread overview]
Message-ID: <20091218143032.GA16595@xs4all.net> (raw)

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 ..

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 ?

Example code:

int real_mutex_lock = 0; // can use int since mutex ops are barriers
struct mutex mutex;

// 1. used instead of spinlock() [common case]
while (mutex_trylock(&mutex) == 0) {
	if (real_mutex_lock) {
		mutex_lock(&mutex);
		break;
	}
}
.. have lock, do work
mutex_unlock(&mutex);


// 2. When we want to lock and be able to sleep [seldomly used]
mutex_lock(&mutex);
real_mutex_lock = 1;
smp_wmb();

.. do work ..
real_mutex_lock = 0;
mutex_unlock(&mutex);

Mike.

             reply	other threads:[~2009-12-18 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 14:30 Miquel van Smoorenburg [this message]
2009-12-18 15:26 ` spinlock which can morph into a mutex Andi Kleen
2009-12-18 15:43 ` Peter Zijlstra
2009-12-18 17:14 ` Thomas Gleixner
2009-12-18 18:19   ` Miquel van Smoorenburg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091218143032.GA16595@xs4all.net \
    --to=miquels@cistron.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox