In message <1015293007.882.87.camel@phantasy> you write:
> On Mon, 2002-03-04 at 17:15, Davide Libenzi wrote:
>
> > That's great. What if the process holding the mutex dies while there're
> > sleeping tasks waiting for it ?
>
> I can't find an answer in the code (meaning the lock is lost...) and no
> one has yet answered. Davide, have you noticed anything?
>
> I think this needs a proper solution..
No. From my previous post:
Date: Mon, 4 Mar 2002 17:13:46 +1100
From: Rusty Russell <rusty@rustcorp.com.au>
To: Paul Jackson <pj@engr.sgi.com>
Cc: frankeh@watson.ibm.com, martin.wirth@dlr.de, rusty@rustycorp.com.au, linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] Re: [PATCH] Lightweight userspace semaphores...
Message-Id: <20020304171346.04c9cac6.rusty@rustcorp.com.au>
In-Reply-To: <Pine.SGI.4.21.0203031410310.623951-100000@sam.engr.sgi.com>
References: <20020302090856.A1332@elinux01.watson.ibm.com>
<Pine.SGI.4.21.0203031410310.623951-100000@sam.engr.sgi.com>
On Sun, 3 Mar 2002 14:13:45 -0800
Paul Jackson <pj@engr.sgi.com> wrote:
> On Sat, 2 Mar 2002, Hubertus Franke wrote:
> > But more conceptually, if you process dies while holding a lock ...
> > your app is toast at that point.
>
> Without application specific knowledge, certainly.
>
> Is there someway one could support a hook, to enable
> an application to register a handler that could clean
> up, for those apps that found that worthwhile?
If you want this, use fcntl locks (see TDB). If you don't tell the kernel
what you are doing (which is the reason these locks are fast), it cannot
clean up for you.
One could conceive of a solution where a process told the kernel
"here is where I keep my lock states: if I die, clean up". Of course,
there's a race there too.
IMHO, given that the lock is protecting something which is left in an
unknown state, this is something which would require serious testing
to be proven worthwhile.
Hope that helps,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:37 EST