Re: Fw: Spam: [Bugme-new] [Bug 2829] New: posix_locks_deadlock() loops infinitely

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Sat, 5 Jun 2004 17:25:03 +1000 (EST) Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> At the moment we return false positives and false negatives (and
> apparently freeze solid under some circumstances), so we would be much
> better off not trying to do something that is possibly impossible for
> us to do anyway.
> 
> Besides which, the POSIX spec does not even talk about the interaction
> of POSIX files locks with POSIX thread as far as I can tell, so we are
> basically making up the semantics ...

Here's my (contrived) example:

Process P1 contains threads T1 and T2
Process P2

I am using "process id" and "thread id" in the POSIX sense.  These are
exclusive, whole file locks for simplicity.

T1 locks file F1 -> lock (P1, F1)
P2 locks file F2 -> lock (P2, F2)
P2 locks file F1 -> blocks against (P1, F1)
T1 locks file F2 -> blocks against (P2, F2)

Is this deadlocked?  If you use "process id" as the lock owner, then maybe.
Note that T2 is allowed to remove lock (P1, F1) ...
So if the OS said "deadlocked" then it may have given a false positive ...
If the OS didn't say "deadlocked" then it may have given a false negative ...
Whether there is a deadlock, is entirely up to the behaviour of the
application P1 and the OS cannot predict that ...

Of course, if you use "thread id" as the lock owner, the this is
definitely a deadlock.

Currently Linux (2.6) and Solaris(2.8) report deadlock when T1 tries to
lock F2.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]