[PARPORT] Re: 2.1.96 patches

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.


>> 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)
> 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

        /* 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) {
                        if (waitqueue_active(&pd->wait_q))

What will happen is this:

Driver 1 Driver 2
                       (sleeping, waiting for wakeup)
  release and claim for driver 2
    wakeup 2 (becomes runnable)
  claim_or_block (sleep here)

>> 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