On Tue, Sep 01, 2009 at 08:50:54PM -0700, Garrett D'Amore wrote:
> Nicolas Williams wrote:
> >Er, but one must always be prepared to wait again on a CV on wakeup.
>
> I'm not sure, is this always true? I think threads don't wake up
> typically unless signaled or timed out. But if the CV is used for more
> than one thing, then yes, you need to check again. You also need to
> check the condition anyway, because you have to assume the lock was
> dropped. But that's not quite the same thing is it? ...
I was referring to the need to check the condition. Which is why the
code I quoted has a loop around cv_timedwait(). Clearly one need not do
that on _error_ or _timeout_, only on success.
> > So
> >what should happen is that cv_reltimedwait*() should output the amount
> >of time left.
>
> This would be nice. ...
But that's what the manpage says! (Including the one updated by this
case, as updated, as well as before.) Which means, IMO, that the
mentioned drivers can get by with cv_reltimedwait*().
So the loop I quoted should be changed to:
/* wait loading run_text until completed or timeout */
clk = drv_usectohz(1000000);
while (!(sc->sc_flags & IWH_F_PUT_SEG)) {
if ((clk = cv_reltimedwait(&sc->sc_put_seg_cv, &sc->sc_glock,
clk)) < 0) {
break;
}
}
> Which goes to my original suggestion to Obsolete the legacy relative
> calls.
It depends though. Is there something special about the wall clock
timedwait functions w.r.t. suspend and real-time semantics? I imagine
the answer is "no", in which case I think you're right, the absolute
timed wait functions should be obsoleted, period.
Nico
--
