public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Edgar Toernig <froese@gmx.de>
To: Doug Siebert <dsiebert@divms.uiowa.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Fast Userspace Mutexes (futex) vs. msem_*
Date: Fri, 08 Mar 2002 23:04:32 +0100	[thread overview]
Message-ID: <3C893570.767929F9@gmx.de> (raw)
In-Reply-To: <200203080615.g286Fqh24770@server.divms.uiowa.edu>

Doug Siebert wrote:
> 
> 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.

And what is "right"?  You have two problems:

 - The kernel has no idea of how many locks a dying process holds.  The
   kernel only starts to know about a lock when another process has to
   wait for it.

 - Locked data may be in an inconsistent state.  The kernel has no idea
   how to "repair" it.

I once suggested to send a signal to all processes that share a PROT_SEM
page with the dying process[1].  But even then it's pretty difficult for
the other processes to decide which locks were held by the dead one.
You need additional data and handling in userspace for that.  But at
least it would help them to know about the dead and in the unhandled
case it would kill all possibly affected processes.  Doing that in
userspace would require a manager process with all its ugliness.

Ciao, ET.


[1] I've no idea how difficult it would be to find these processes.

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

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

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=3C893570.767929F9@gmx.de \
    --to=froese@gmx.de \
    --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