All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Alex Shi <alex.shi@linaro.org>, Andi Kleen <andi@firstfloor.org>,
	Michel Lespinasse <walken@google.com>,
	Rik van Riel <riel@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>,
	Jason Low <jason.low2@hp.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rwsem: Comments to explain the meaning of the rwsem's count field
Date: Thu, 01 May 2014 16:18:44 -0400	[thread overview]
Message-ID: <5362AC24.9050508@hurleysoftware.com> (raw)
In-Reply-To: <1398966637.2970.129.camel@schen9-DESK>

On 05/01/2014 01:50 PM, Tim Chen wrote:
> It takes me a while to understand how rwsem's count field mainifest
> itself in different scenarios.  I'm adding comments to provide a quick
> reference on the the rwsem's count field for each scenario where readers
> and writers are contending/holding the lock.  Hopefully it will be useful
> for future maintenance of the code and for people to get up to speed on
> how the logic in the code works.

Except there are a lot of transition states for the count that look like
stable states for some other condition, and vice versa.

For example, 0xffff000X could be:
1. stable state as described below.
2. 1 or more (but not X) readers active,
    1 writer which failed to acquire and has not yet backed out the adjustment
    0 or more readers which failed to acquire because of the waiting writer
        and have not yet backed out
3. 1 writer active,
    1 or more readers which failed to acquire because of the active writer and
        have not yet backed out
4. maybe more states where a owning writer has just dropped the lock

Because of this, it's hazardous to infer lock state except for the specific
existing tests (eg., the count observed by a failed reader after it has
acquired the wait_lock).

Regards,
Peter Hurley

> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
>   kernel/locking/rwsem-xadd.c | 22 ++++++++++++++++++++++
>   1 file changed, 22 insertions(+)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 1d66e08..305c15f 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -12,6 +12,28 @@
>   #include <linux/export.h>
>
>   /*
> + * Meaning of the rw_semaphore's count field:
> + * (32 bit case illustrated, similar for 64 bit)
> + *
> + * (listed in decreasing order)
> + * 0x0000000X  X readers active, no writer waiting (X*ACTIVE_BIAS)
> + * 0x00000000  rwsem is unlocked, and no one is waiting for the lock
> + * 0xffff000X  X readers active, writer and/or reader waiting.
> + *	       (X*ACTIVE_BIAS + WAITING_BIAS)
> + * 0xffff0001  (1) one writer active, nobody queued. (ACTIVE_WRITE_BIAS)
> + *	       or
> + *	       (2) one reader active, writer(s) queued.
> + *		   (WAITING_BIAS + ACTIVE_BIAS)
> + * 0xffff0000  There are writers or readers queued but none active
> + *	       (WAITING_BIAS), a writer can try to grab the lock and
> + *	       take itself off wait list if awake.  Writer who has just
> + *	       completed its task seeing this count will try to
> + *	       wake people up from wait list.
> + * 0xfffe0001  Writer active, readers/writer queued
> + *	       (ACTIVE_WRITE_BIAS + WAITING_BIAS)
> + */
> +
> +/*
>    * Initialize an rwsem:
>    */
>   void __init_rwsem(struct rw_semaphore *sem, const char *name,
>


  parent reply	other threads:[~2014-05-01 20:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 17:50 [PATCH] rwsem: Comments to explain the meaning of the rwsem's count field Tim Chen
2014-05-01 18:38 ` Davidlohr Bueso
2014-05-02 18:05   ` Tim Chen
2014-05-01 20:18 ` Peter Hurley [this message]
2014-05-01 23:05   ` Tim Chen
2014-05-02 13:10     ` Randy Dunlap
2014-05-02 16:09       ` Tim Chen
2014-05-02 20:00     ` Peter Hurley
2014-05-02 21:25       ` Tim Chen

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=5362AC24.9050508@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linaro.org \
    --cc=andi@firstfloor.org \
    --cc=davidlohr@hp.com \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=walken@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.