All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Peter Wächtler" <pwaechtler@loewe-komp.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: frankeh@watson.ibm.com, arjanv@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: furwocks: Fast Userspace Read/Write Locks
Date: Fri, 08 Mar 2002 10:21:08 +0100	[thread overview]
Message-ID: <3C888284.8030206@loewe-komp.de> (raw)
In-Reply-To: <E16j95K-00047G-00@wagner.rustcorp.com.au>

Rusty Russell wrote:

> In message <20020307153228.3A6773FE06@smtp.linux.ibm.com> you write:
> 
>>On Thursday 07 March 2002 07:50 am, Arjan van de Ven wrote:
>>
>>>Rusty Russell wrote:
>>>
>>>>This is a userspace implementation of rwlocks on top of futexes.
>>>>
>>>question: if rwlocks aren't actually slower in the fast path than
>>>futexes,
>>>would it make sense to only do the rw variant and in some userspace
>>>layer
>>>map "traditional" semaphores to write locks ?
>>>Saves half the implementation and testing....
>>>
>>I m not in favor of that. The dominant lock will be mutexes.
>>
> 
> To clarify: I'd love this, but rwlocks in the kernel aren't even
> vaguely fair.  With a steady stream of overlapping readers, a writer
> will never get the lock.
> 
> Hope that clarifies,


But you talk about the current implementation, don't you?
Is there something to prevent an implementation of rwlocks in the
kernel, where a wrlock will lock (postponed) further rdlock requests?

I mean: the wrlocker prevents newly rdlocks to succeed and waits for the
current rdlockers to release the lock an then gets the lock..



  parent reply	other threads:[~2002-03-08  9:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-07 12:11 furwocks: Fast Userspace Read/Write Locks Rusty Russell
2002-03-07 12:40 ` Peter Wächtler
2002-03-07 14:41   ` Hubertus Franke
2002-03-07 12:50 ` Arjan van de Ven
2002-03-07 15:33   ` Hubertus Franke
2002-03-07 15:42     ` Arjan van de Ven
2002-03-07 19:11       ` Hubertus Franke
2002-03-07 20:17         ` H. Peter Anvin
2002-03-08  6:27           ` Rusty Russell
2002-03-08  6:29             ` H. Peter Anvin
2002-03-08  7:09               ` Rusty Russell
2002-03-08 19:32             ` Jamie Lokier
2002-03-08  1:22     ` Rusty Russell
2002-03-08  3:26       ` H. Peter Anvin
2002-03-08  9:21       ` Peter Wächtler [this message]
2002-03-08 18:13         ` Hubertus Franke
2002-03-09  4:50         ` Rusty Russell
2002-03-11 18:47           ` Hubertus Franke
2002-03-07 15:28 ` Hubertus Franke

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=3C888284.8030206@loewe-komp.de \
    --to=pwaechtler@loewe-komp.de \
    --cc=arjanv@redhat.com \
    --cc=frankeh@watson.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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.