Re: await & asleep

From: Daniel Eischen (deischen_at_freebsd.org)
Date: 07/27/05

  • Next message: Sam Pierson: "Re: Atheros, hardware access layer, collisions" 
    Date: Wed, 27 Jul 2005 13:25:22 -0400 (EDT)
To: Scott Long <scottl@samsco.org>

    On Wed, 27 Jul 2005, Scott Long wrote:

    > Daniel Eischen wrote:
    >
    > >
    > > 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.

    Traditionally, you did splXXX() then tsleep(). But splXXX() has been
    deprecated and you need to use mutexes for protection. If you are going
    to sleep for an event, that is cv_wait() and friends and you use the
    mutex for protection. It's hard to imagine that queueing disk I/O
    requests and their completions don't need mutexes (or lockmgr?) for
    protection, but I'll take your word for it. 

    -- 
DE
_______________________________________________
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: Sam Pierson: "Re: Atheros, hardware access layer, collisions"

    Relevant Pages

    • Re: await & asleep
      ... Can you explain why tsleep and wakeup should no longer be ... A mutex is not a replacement for sleep. ... covered by mutexes, Giant or otherwise. ...
      (freebsd-hackers)
    • Re: WaitForSingleObject() will not deadlock
      ... And in what way am I wrong about Windows mutexes? ... expectations would violate the *documented* mutex behavior). ... building only experimental systems (my first synchronization system was ...
      (microsoft.public.vc.mfc)
    • Re: msleep() on recursivly locked mutexes
      ... Further the idea that holding a mutex "except for when we sleep" is a ... This is basically when I need to exit mutexes. ... I agree with the other comment that all drivers should be multi-thread ... lock a mutex again. ...
      (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: Obscure mutex problem
      ... PTHREAD_MUTEX_RECURSIVE to make the mutexes work at all... ... mutex fine, and then thread B would attempt to lock it, but instead ... That pre-NPTL-Linux does not support 'real' multithreading 'but some ...
      (comp.os.linux.development.apps)