Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).

From: Brian F. Feldman (green_at_freebsd.org)
Date: 04/15/04

  • Next message: Cyrille Lefevre: "bin/41071: make NO to NO_ transition patch" 
    To: Robert Watson <rwatson@freebsd.org>, Seigo Tanimura <tanimura@tanimura.dyndns.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-arch@freebsd.org
Date: Thu, 15 Apr 2004 16:36:30 -0400

    John-Mark Gurney <gurney_j@efn.org> wrote:
    > How does this sound to people? I have some code starting to implement
    > this, but I haven't gotten very far with it yet...

    You know, now I think Seigo's right on the money that due to the nature of
    the recursion of kqueue's current implementation, it's impossible to get
    right with this train of thought. So, let's redesign:
            * The kqueue object the user controls needs a mutex.
            * The lists (selinfo, mostly) that knotes are on need locking.
            * The filterops that kqueue calls out MUST be called with some
              kind of locking on the lists that the kqueue is on, and the
              user MUST be able to grab any kind of lock from inside a
              filterop.
            * At some point the object being observed must call back into
              kqueue to add itself. We'll end up getting deadlocks if the
              locks kqueue holds are not the ones required to add the
              object to klists and held when we do the f_attach().
            * Anything that calls KNOTE() or KNOTE_ACTIVATE() directly
              will end up recursing back on itself if we don't convert
              it to putting the new event on a work queue. How
              filt_procattach() calls KNOTE_ACTIVATE() or filt_proc()
              calls kqueue_register() is a very good example.
            * The functions that need to be exported are:
              * KNOTE()/KNOTE_ACTIVATE() <- put on a workqueue
              * kqueue_register() <- put on a workqueue
              * knote klist/(kn_selnext) linking and unlinking
              * knote klist/(kn_selnext) is disappearing
              The last two are the only ones that are not called recursively
              and should have easy locking semantics.
    Nothing is currently designed to work with anything even remotely not
    looking like spl(), so we have to either flatten it out (using workqueues)
    or change semantics so that when KNOTE() is called it acts like the closure
    that we pretend it is. Of course, the easy way to do this is with a worker
    queue/condvar/mutex/thread. What other ways do we have available to turn
    KNOTE() into a closure, bearing in mind that the entire point of the
    mechanism is that there is no memory allocation at the time of event
    generation -- only when events are defined (by the user or recursively by
    other events). 

    -- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
_______________________________________________
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: Cyrille Lefevre: "bin/41071: make NO to NO_ transition patch"

    Relevant Pages