PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009]

[Garrett D'Amore]

Nicolas Williams wrote:
> On Tue, Sep 01, 2009 at 04:13:02PM -0700, Rafael Vanoni wrote:
>   
>> Nicolas Williams wrote:
>>     
>>> Looks like a candidate for cv_reltimedwait().
>>>       
>> It seemed that way to me before the first code reviewer (Madhavan) 
>> pointed out that with cv_reltimedwait() the timer would be reloaded with 
>> the same delta at each iteration - where it had originally specified an 
>> absolute time limit.
>>     
>
> 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 mean, 
cv_wait(9F) makes no claims that a thread will wake *other* the 
situation where cv_signal or cv_broadcast was used on the cv.

Likewise, the only way that I can see that cv_timedwait() returns is 
either if the cv was signaled, or the timeout expired.  (And which case 
is reflected in the return value.)

>  So
> what should happen is that cv_reltimedwait*() should output the amount
> of time left.
>   

This would be nice.   However, drivers can work around this by calling 
ddi_get_lbolt64() (or gethrtime() or whatever other method is needed) to 
look at the time before and after the call.

Generally, if you can express a relative timeout, and if you can get the 
current time, then you don't need a direct absolute interface.

Which goes to my original suggestion to Obsolete the legacy relative calls.

    - Garrett
> Nico
>