Re: [RFC] sysctl locking

From: Don Lewis (truckman_at_FreeBSD.org)
Date: 10/13/04

  • Next message: Poul-Henning Kamp: "tty code, status and future..." 
    Date: Wed, 13 Oct 2004 14:17:14 -0700 (PDT)
To: ssouhlal@FreeBSD.org

    On 13 Oct, Suleiman Souhlal wrote:
    > Hi,
    >
    > On Oct 11, 2004, at 3:30 PM, Don Lewis wrote:
    >> There seems to be a lot of locking/unlocking overhead in the oid lookup
    >> and oid tree manipulation code. Doing the traversals at each level of
    >> the tree without holding a lock for the entire time makes me nervous,
    >> though I can't point to any specific problem. It might be better to
    >> just hold a single lock across then entire lookup, insertion, or
    >> deletion operation.
    >
    > Thanks for your reply! I think you are right. It would also make the
    > locking much simpler. However, there is the problem that sysctl
    > handlers can sleep, so we shouldn't be holding a mutex when calling
    > them..

    Unlock the mutex after doing the lookup and getting ownership of the
    oid, and before calling the handler.

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Poul-Henning Kamp: "tty code, status and future..."

    Relevant Pages

    • Re: conditional variable does not unlock mutex
      ... The program hangs due to ... print_hello_message_functionwaits for the mutex, ... should be unlocked after calling pthread_cond_signal. ... call it while holding or not holding the mutex. ...
      (comp.programming.threads)
    • Re: need some debugging help
      ... >>Anyway, I got some debugging output, and I've attached dmesg output. ... - I tried holding Giant when calling tsleep, ... - I tried not holding a mutex at all when calling tsleep, ...
      (freebsd-current)
    • Re: PTHREAD_PROCESS_SHARED on GNU/Linux
      ... a stock Linux kernel won't release the lock on behalf of the ... mutex, so you'd probably have to stop everything and re-initialize the ... shared memory if any process dies unexpectedly. ... If a process dies unexpectedly while holding a mutex, ...
      (comp.programming.threads)
    • Re: Biscournus
      ... I haven't yet but I printed the instructions and they are calling to me. ... I'm holding off because I have no clue what I would do with it after it's ...
      (rec.crafts.textiles.needlework)
    • Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*)
      ... Holding a mutex across a malloc() call is ... >> not allowed because malloccan sleep, ...
      (freebsd-current)