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.030 / U:0.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site