mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Doug Siebert <dsiebert@divms.uiowa.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Fast Userspace Mutexes (futex) vs. msem_*
Date: Sat, 9 Mar 2002 15:23:59 +1100	[thread overview]
Message-ID: <20020309152359.6a450af0.rusty@rustcorp.com.au> (raw)
In-Reply-To: <200203080615.g286Fqh24770@server.divms.uiowa.edu>
In-Reply-To: <200203080615.g286Fqh24770@server.divms.uiowa.edu>

On Fri, 8 Mar 2002 00:15:52 -0600 (CST)
Doug Siebert <dsiebert@divms.uiowa.edu> wrote:
 
> The direction that the futex implementation is going is looking a lot like
> how they are implemented on HP-UX (as well as Tru64 and AIX)  I am curious
> though why the case of "what happens if the process holding the lock dies"
> is considered unimportant by some people.  It wouldn't be all that much
> more work to "do it right" (IMHO) and handle this case.  AFAIK, on HP-UX
> the implementation kept a "locker id" and a linked list of waiters' lock
> ids (to allow first come first served as well as handling the case of a
> lock holder dying)

Fundamentally, these locks are fast because they *don't* tell the kernel.
Also, if you die with a lock, "autocleaning" it is often far worse then
just locking up, since the data it was protecting may be inconcsistant.

At the end of the day, this is the place for an application-specific
answer.  And this is nothing that can't be done in userspace (ie. if
you can't get the lock for some length of time, notify the lock master
and it will do all the cleanups and release the lock).

Hope that clarifies,
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

      parent reply	other threads:[~2002-03-09  7:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-08  6:15 Doug Siebert
2002-03-08  6:34 ` Davide Libenzi
2002-03-08 22:04 ` Edgar Toernig
2002-03-12 16:50   ` Bill Davidsen
2002-03-09  4:23 ` Rusty Russell [this message]

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=20020309152359.6a450af0.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=dsiebert@divms.uiowa.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®