lkml.org 
[lkml]   [2002]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fast Userspace Mutexes (futex) vs. msem_*
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.053 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site