Tim Waugh (firstname.lastname@example.org)
Thu, 16 Apr 1998 20:33:06 +0100 (BST)
On Thu, 16 Apr 1998, Andrea Arcangeli wrote:
> The bug is that you exchanged lp_schedule() with lp_yield(). lp_schedule()
> is called so since it _must_ schedule() in _some_ way inside it.
> lp_yield() can schedule() only if need_resched is 1.
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
Driver 1 Driver 2
(sleeping, waiting for wakeup)
wakeup 2 (becomes runnable)
(run out of time) (gets processor)
"Cool, I've been woken up by parport!"
Have I got that right?
> 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,
-- To unsubscribe, send mail to: email@example.com --
-- 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