Philip Blundell (pb@nexus.co.uk)
Mon, 13 Jul 1998 15:56:02 +0100
>Is it? Changing the "waiting & 2" test to "waiting & 1" wouldn't fix it,
>because waiting is 3.
I think it would actually. What happens (I think) is this:
Thread A is trying to claim the port using parport_claim_or_block(). It
discovers it's busy and sets waiting==2 to tell parport_claim() it can sleep.
Somewhere in parport_claim() it gets interrupted by thread B, which wants to
release the port. It sees thread A is waiting (because it, spuriously, checks
"waiting & 2") and gives it the port. Because thread A hasn't got as far as
sleeping yet its waitqueue isn't active and nobody is woken.
Thread A then runs again unaware of what's happened behind its back. It sees
that the port is still in use (not realising that it's now the owner) and
commits to going to sleep. It sets bit 0 of `waiting' as well and goes to
sleep. Since it now owns the port nobody else can release it and so we have
deadlock.
>My understanding of the bits in waiting is:
>bit 0: I am in the wait-queue.
>bit 1: I can be woken.
You may be right (in which case everything I've written above is probably
bogus). I admit my hypothesis above doesn't explain the wait-list being empty.
I'll look again when I get home this evening.
p.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:57 EST