Andrea Arcangeli (arcangeli@mbox.queen.it)
Thu, 16 Apr 1998 23:17:21 +0200 (CEST)
On Thu, 16 Apr 1998, Tim Waugh wrote:
>Must it? Okay, I can change that.
OK.
>> As second it' s not smart to schedule() if _then_ we will have to
>> sleep_on() in parport_claim_or_block().
>
>No, but equally it's not smart to do a release followed immediately by a
>claim if the other guy has a wakeup function registered (on a uniprocessor
>machine at least), as they will wake up only to find that the port is
>already claimed.
>
>Driver 1 Driver 2
> (sleeping, waiting for wakeup)
>(yield:)
> release
> wakeup 2 (becomes runnable)
> claim (succeeds)
> ...
> (run out of time) (gets processor)
> "Cool, I've been woken up by parport!"
> claim (fails)
>
>Have I got that right?
No. You missed the underlined parport_claim() before wake_up the other
waiter:
[..]
/* If anybody is waiting, find out who's been there longest and
then wake them up. (Note: no locking required) */
for (pd = port->waithead; pd; pd = pd->waitnext) {
if (pd->waiting & 2) {
parport_claim(pd);
^^^^^^^^^^^^^^^^^
if (waitqueue_active(&pd->wait_q))
wake_up(&pd->wait_q);
return;
[..]
What will happen is this:
Driver 1 Driver 2
(sleeping, waiting for wakeup)
(yield:)
release and claim for driver 2
wakeup 2 (becomes runnable)
claim_or_block (sleep here)
running
yield()
etc..etc...
>> With the current implementation it can happen that while we are adding the
>> pardevice to the waiters list (at the end of parport_claim()) another CPU
>> could run parport_release(). The other CPU could run "port->cad = NULL;"
>> while the first CPU has just passed the test:
>
>Your patch looks correct to me. Thanks,
Thanks to you!
Andrea[s] Arcangeli
-- 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:38 EST