Re: await & asleep

From: Scott Long (scottl_at_samsco.org)
Date: 07/27/05

  • Next message: Daniel Eischen: "Re: await & asleep" 
    Date: Wed, 27 Jul 2005 11:00:15 -0600
To: Daniel Eischen <deischen@freebsd.org>

    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
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Daniel Eischen: "Re: await & asleep"

    Relevant Pages

    • Re: await & asleep
      ... A mutex is not a replacement for sleep. ... > implement some of what tsleep does, ... > covered by mutexes, Giant or otherwise. ... deprecated and you need to use mutexes for protection. ...
      (freebsd-hackers)
    • strange KASSERT in _sleep()
      ... tsleep() maps to _sleepwith lock = NULL, ... which simplifies for tsleep(foo, ...) where foo!= lbolt to ... why do I have to hold Giant or have timo!= 0 when calling tsleep? ...
      (freebsd-hackers)
    • Re: msleep() on recursivly locked mutexes
      ... Further the idea that holding a mutex "except for when we sleep" is a ... release it during sleep you probably should invalidate all assumptions ... This is basically when I need to exit mutexes. ... it is not always possible to drop the blocking lock ...
      (freebsd-hackers)
    • Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127
      ... They don't actually 'sleep', but they do deschedule the thread. ... Users of mutexes "agree" to never do anything that in indeterminately long while holding the mutex so you are SUPPOSED to get control back in a "short" period of time. ...
      (freebsd-current)
    • Re: [RFC] locking.9
      ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
      (freebsd-current)