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

From: Pawel Jakub Dawidek (pjd_at_FreeBSD.org)
Date: 04/08/04

  • Next message: Robert Watson: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)." 
    Date: Thu, 8 Apr 2004 23:59:48 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

    On Thu, Apr 08, 2004 at 11:40:07PM +0200, Poul-Henning Kamp wrote:
    +> >As was discussed, it will be helpful to have functions, that are able
    +> >to acquire lock recursively, even if lock itself isn't recursable.
    +>
    +> Sounds evil to me...

    Why? I don't think that better is to just use MTX_RECURSE if we don't need
    it in 90% of cases. And sometimes it is really hard to pass information if
    lock is held or not, just like for that rwatson's kqueue thing.

    +> Does your patch also make witness aware of this ?

    Nope, it is just a proof-of-concept and as jhb@ pointed out, we want
    to keep our interface simple, so it probably will never reach the tree. 

    -- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd@FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!

  • Next message: Robert Watson: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)."

    Relevant Pages

    • Re: device struct bloat
      ... acquires the semaphores for _all_ the devices in the tree. ... lock in order to probe drivers for the child. ... parent again. ...
      (Linux-Kernel)
    • Re: device struct bloat
      ... Just locking the tree root is not enough? ... modifying operation to descend into the tree). ... lock an element and check if its still linked into the tree. ...
      (Linux-Kernel)
    • Re: Locking of nodes in tree for concurrent access
      ... When I traverse down the tree I close each node's own read write lock when looking for the appropriate child node to pick to continue the traversal and open the lock once I have picked the right child node and continue the traversal to the next deeper level in the same way. ... If the former, then your AtomicInteger mechanism is exactly equivalent to a ReadWriteLock, with reader threads acquiring it for read, and writer threads for write. ... I *think* you don't need to worry about the window of vulnerability that exists between unlocks and locks when descending the tree - or rather, i can't see how closing it would protect you. ...
      (comp.lang.java.programmer)
    • Re: device struct bloat
      ... Just locking the tree root is not enough? ... modifying operation to descend into the tree). ... I'd first start by asking if you want to lock all the children or the ... parent again. ...
      (Linux-Kernel)
    • [BUG] deadlock between configfs_rmdir() and sys_rename() (WAS Re: [RFC][PATCH 4/4] configfs: Make mu
      ... groups tree locking in configfs_detach_prep. ... deadlock parameters), we get the dead lock alerts: ... INFO: lockdep is turned off. ...
      (Linux-Kernel)