await & asleep

[Scott Long]

Daniel Eischen wrote:

> On Wed, 27 Jul 2005, Scott Long wrote:
> 
> 
>>Daniel Eischen wrote:
>>
>>>On Wed, 27 Jul 2005, Norbert Koch wrote:
>>>
>>>
>>>
>>>>>>The functions await() and asleep() in kern_synch.c
>>>>>>are marked as EXPERIMENTAL/UNTESTED.
>>>>>>Is this comment still valid? Does anyone have used
>>>>>>those functions successfully? Should I better not
>>>>>>use them in my device driver code for RELENG_4?
>>>>>>How do I correctly cancel a request (as I should do
>>>>>>according to the man page): "asleep (NULL, 0, NULL, 0)"?
>>>>>
>>>>>The await family was removed in 5.x and beyond, so trying to
>>>>>use them in 4.x will make your driver very unportable.  There
>>>>>are better ways than await to handle delayed events.
>>>
>>>
>>>Well, there's tsleep() and wakeup() for FreeBSD < 5.0.  Other
>>>than that, what else can you do?  These functions are deprecated
>>>in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should
>>>really use those instead of tsleep() and wakeup().
>>>
>>>It seems the kernel in -current is still using tsleep() and
>>>wakeup() in some places.  I thought we got rid of all these...
>>>
>>
>>????  Can you explain why tsleep and wakeup should no longer be
>>used?  I wasn't aware that they were formally deprecated.
> 
> 
> My mistake then.  I thought they were deprecated when mutex and
> CVs were introduced.  There is no need for them except for compatability,

Incorrect.  A mutex is not a replacement for sleep.  CV's and semaphores
implement some of what tsleep does, but tsleep is absolutely appropriate
when you want to sleep for an event (like disk i/o completing) and don't
need to worry about mutexes.  Not every inch of the kernel needs to be
covered by mutexes, Giant or otherwise.

> and the priority argument of tsleep() doesn't have any meaning
> any longer, right?
> 

I thought it did, but John can give the definitive answer.

Scott